SimboAlphus

The speech and language stack is the product and it is sold as such. Simbo offers the capability as raw APIs for partners to embed as well as a finished application, which is only possible where the model work is the asset rather than a workflow wrapped around someone else's.

As infrastructure, the oversight model is largely whatever the integrating partner builds, and Simbo does not describe a review gate, confidence threshold or escalation behavior for its own provider application. The quality score interface is a useful primitive toward oversight rather than an oversight mechanism in itself: it gives an integrator something to act on but says nothing about what happens by default, what score triggers what, or whether any human is required before a note is used.

The strongest disclosure is an architectural feature rather than a published figure. Simbo exposes APIs that return a quality score and metadata alongside the generated note. A programmatic per note quality signal is a real transparency primitive: it lets an integrator detect low confidence output and route it differently.

The delivery architecture is also described concretely, with audio upload or websocket streaming and notes returned within about two minutes carrying annotated structured data. No accuracy figure or model card for SimboAlphus itself is published, and the evaluation page that names the models tested gives no figure for the product; the vendor's blog quotes generic industry accuracy ranges in close proximity to its product in a way a reader could easily mistake for product performance.

Six models are named.

The vendor's evaluation page names the models it tested for note generation: GPT, Llama 2, Mistral, Claude, Command and Med-PaLM. It describes choosing the best output across twelve generations, six models attempted twice each. The practice automation page separately states that the product uses multiple large language models and selects the best response using a proprietary scoring algorithm. Read together, those establish that clinical conversations are processed by several third party model providers rather than one, and both pages are the vendor's own.

Naming the model layer is a larger disclosure than naming a hosting provider.

What is missing is a subprocessor list retrievable without asking, naming every party, with the retention and training terms that govern a conversation once it arrives. Neither is published. So which companies may generate a note can be learned, but not what those companies keep, for how long, or whether any of it trains anything.

The naming sits in an evaluation article rather than a subprocessor list or a trust page, so it takes two pages to reach, and the evaluation carries no date while the models it names include older generations, so the roster may not be current.

The component business model sharpens the retention question. Where this engine is embedded in a partner's product there are two retention questions rather than one: a partner can make a clean commitment about its own environment while content is streamed to and held by this supplier under different terms, so a deletion request may reach one party and not the other. Nothing published establishes what persists on the supplier side after a response is returned, or whether derived artifacts such as quality scores and structured annotations are kept separately from the audio. And a component supplier accumulates encounters from every partner deployment rather than from one customer base, across six model providers rather than one.

Encryption and privacy by design claims in this company's material attach to its separate phone agent product, and a security claim does not transfer between products of the same vendor.

No study, controlled evaluation, third party rating, named customer or documented deployment is published for SimboAlphus. The one product level claim, saving physicians up to three hours daily, uses the unfalsifiable up to construction.

Simbo also publishes a large volume of generic category blog content in which industry wide statistics on AI scribe accuracy and documentation time appear alongside its own product, and in at least one instance a content manager is cited as an authority on EHR integration. None of that material constitutes evidence about this product.

This product has no published retention schedule, deidentification practice or training use statement.

Encryption and privacy by design claims appearing in this company's material attach to its separate phone agent product, and a claim made about one product does not carry over to another. That is a general rule and it matters most for multi product vendors, where a reader scanning a website will accumulate assurances that were never made about the thing they are buying.

The component model gives PHI stewardship a specific shape. Where the engine is embedded in a partner's product, there are two retention questions rather than one: what the partner keeps, and what this vendor keeps while processing. A partner can make a clean commitment about its own environment while content is streamed to and held by a supplier under different terms. So a clinician's deletion request may reach one party and not the other.

The interface description makes it concrete. Content reaches this vendor by streaming or upload, and structured data, quality scores and metadata are returned. Nothing published says what persists on this side after a response is returned, in what form, or whether derived artifacts such as quality scores and structured annotations are retained separately from the audio.

The training question is unanswered in either direction, and it is more consequential for a component supplier than for a single product vendor, because a supplier accumulates encounters from every partner deployment rather than from one customer base.

No business associate agreement posture specific to this product is published, and the policy pages that would normally carry one do not exist. The company's site footer holds product links, a postal address and social accounts, with no privacy policy, no terms of service and no security or trust page behind it.

The component model makes the question structurally more complicated than it is for a direct vendor. Where the engine is embedded in another company's product, the contractual chain runs from the healthcare organization to that company, and from that company to this vendor. Under the United States rule a business associate must itself have written agreements with the subcontractors it uses to handle protected health information, so the arrangement is provided for. What it does not guarantee is visibility. A clinician contracting with a scribe brand may never learn that a separate company processes their encounters, and the agreement they signed will name the brand rather than the processor.

Nothing published says which scribe brands embed this engine, and nothing says what happens to data if a supplier relationship ends. The published evaluation material indicates several third party model providers are involved, which makes the chain longer still.

For this vendor directly, a further complication follows from the corporate footprint. The company is headquartered in the United States with a significant presence and named leadership in India. Offshore processing or support access is a permitted arrangement under the rule and it must be papered, and nothing says whether personnel outside the United States can reach protected health information, in what circumstances, or how that access is logged.

Security claims appearing in this company's material for its separate phone agent product do not transfer to this one.

No named or dated attestation, no report of either type and no trust center exists for this product. The company's site footer carries product links and social accounts only, with no security page, privacy policy or terms behind it.

What is published in their place is the phrase banking grade security, on the product's own sign-in estate. That is marketing language rather than assurance, of a piece with military grade, enterprise grade and bank level. None of them names a standard, none is awarded by anyone, and none tells a buyer what was examined. The accompanying claim that the product follows all health privacy guidelines is a statement of intent about a statute for which no certification exists.

The vendor's own published guidance makes the gap conspicuous. Its blog advises healthcare leaders to verify that a scribe vendor holds certifications such as SOC 2 or HITRUST before selecting one, and lists those alongside encryption, access controls, audit logs and breach handling as the items to check. That is broadly the right checklist. The vendor has not published any of the certifications it names.

One detail in that guidance is worth correcting rather than repeating, because it will mislead the readers it is written for. It advises buyers to verify health privacy certification. There is no such certification. Compliance with that statute is a contractual and operational posture, not an award, which is why the agreement matters more than any badge.

The component model raises the stakes. Where other software companies embed this engine, they inherit its posture and pass it downstream to clinicians who never see the name.

No clearance claimed and none required for ambient documentation. No device pathway attaches to a note the clinician reviews and signs.

The product is narrow in scope. Ambient capture produces a note with structured data; no coding engine, risk adjustment scoring, decision support layer, patient facing component or order generation appears within it.

One feature of the interface offering bears directly on the reasoning that keeps ambient documentation outside device oversight. The vendor states that interfaces are available to obtain a quality score alongside the note and its structured data. So the engine emits a confidence or quality signal.

The whole value of that depends on what happens next. A quality score returned to an integrating partner is useful only if that partner surfaces it to the clinician at the moment of review. If it is used internally for monitoring, or consumed by the partner and discarded, the clinician reviewing the note sees the same undifferentiated draft they would see without it, and the signal has not reached the person whose oversight the regulatory position depends on.

So the question is not whether confidence is measured but whether it is displayed. What the score represents is published: the vendor's evaluation page defines it as a function of hallucination and coverage, and defines both. What remains open is whether any clinician ever sees it. That turns on whether products built on this engine show the score, at what threshold it changes the clinician's experience, and what a low score does, none of which is published.

Nothing published establishes whether a review gate is enforced by the engine or left entirely to the integrator.

The product materials offer no fairness statement, subgroup analysis, accent or dialect performance disclosure, or language coverage claim.

The component model changes who bears this question, and that is the point worth making here rather than repeating the general argument. Where this engine is embedded in other companies' products, the speech performance a clinician experiences is this vendor's, while the brand they contract with, complain to and evaluate is someone else's. So the party that holds the speech model, and could publish subgroup evidence, is not the party a buyer can ask, and the party a buyer asks may not have the evidence or the access to generate it.

That is a structural reason the question goes unanswered, not a failing unique to this vendor. It also means that for a scribe product whose speech model is licensed rather than its own, the accuracy evidence that matters, and the speaker populations it covers, sit with the supplier.

The vendor's own published material shows the issue is understood. Its blog states that AI can learn biases from training data, that this may produce unfair or incorrect notes, and that regular human review helps reduce the problem. The vendor names the risk accurately and publishes no evidence about its own system, though the quality score the engine emits suggests it already measures output quality in some form.

The vendor publishes a page setting out how documentation quality is measured, and it defines each term rather than gesturing at them. A hallucination is an utterance in the generated note that was not discussed or implied during the conversation. Coverage is how much of the relevant information present in the input appears in the note. An adverse score sums hallucinations and omissions. The confidence score the interface returns is defined as a function of hallucination and coverage, rising with coverage and falling with hallucinations. The denominator is published as well: 133 patient visits from outpatient clinics across more than fifteen specialties, three runs each, every visit attempted twice against each of six models.

That is real disclosure: the vendor publishes candid findings about how unreliable the underlying models are, including that hallucinations vary randomly between one and seven utterances on identical repeated prompts, and that coverage swings between 45 and 85 percent. A vendor publishing the instability of the technology it sells is being straight about it.

What is missing is the number that would make any of it checkable. The product's own results appear only as distribution curves, described in words as shifting left for hallucinations and right for coverage, with no figure attached to any of them. The product is claimed to do better than the base models, but not by how much, from what baseline, or judged against what reference standard a note is scored wrong. A claim with no number cannot be falsified.

Nothing stands behind the output either. No warranty, no indemnity and no remediation commitment is published, and nothing describes a route for a patient affected by a wrong note. What does exist is a mechanism for challenging an output: a per note quality signal with a published definition, returned programmatically so an integrator can route a low scoring note to a person.

The evaluation page carries no date and several models it tests are older generations, so it may not describe the product as it runs now.

API first rather than integration first, which makes it a different proposition. Simbo provides APIs at multiple levels so partners can embed the scribe stack natively, with audio upload or websocket streaming in and notes with annotated structured data out, plus quality score and metadata endpoints. That is a documented integration surface rather than a list of logos. The finished provider application also spans a wide client range including Linux. No production EHR integration is named on a product page; the specific systems mentioned in Simbo's material appear in generic category blog posts.

There is no published hosting region, residency option or subprocessor detail. Delivery is cloud with real time audio streaming and a provider application across desktop and mobile platforms.

The distribution model matters most here, because it changes how the scribe market as a whole reads. The vendor sells its scribe technology as an interface and development kit, and names its partner categories directly: provider organizations, record system companies, other AI scribe businesses, and human scribe businesses. It offers interfaces at several levels so a partner can present the capability as native inside their own product.

So some products marketed as independent scribes are integrations of this engine, and a clinician using one may have no way to know. Many companies sell AI scribes, and they are not the same number of independent technology stacks. That is not a criticism of anyone. Component suppliers are normal and specialization improves quality. It does mean a buyer comparing two products may be comparing two presentations of one pipeline, and that a security or residency answer given by a reseller describes their deployment rather than the engine.

The useful fact about any scribe product, then, is whether its speech and note generation are its own or licensed, and if licensed, from whom, since residency and retention depend on that supplier rather than only on the brand on the contract.

The vendor states a presence in two countries, and nothing published says where processing runs or whether that differs by partner deployment.

No published rate card and no pricing model stated beyond flexible partnership models tailored to each partner type. For a product sold both direct and as embedded infrastructure, the absence of any commercial structure means a buyer cannot tell whether they would be quoted per clinician, per note, per API call or per partnership.

Client platform coverage is broad and unusual, spanning iPhone, Android, iPad and Mac, Windows and Linux desktops, which matters for clinicians on managed or nonstandard machines. Clinical coverage is not documented, with no specialty count, specialty tuning claim, note format list or supported language list published.