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 behaviour for its own provider application. The quality score API 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. Compare Corti, graded A in this category for a defined clinician in the loop mechanism rather than a component.

Graded on an architectural feature rather than a published figure, and the reasoning matters. Simbo exposes APIs that return a quality score and metadata alongside the generated note. A programmatic per note quality signal is a genuine transparency primitive: it lets an integrator detect low confidence output and route it differently, which is closer in spirit to the published threshold benchmark this index rewards than anything else in the tail of this category.

The delivery architecture is also described concretely, with audio upload or websocket streaming and notes returned within about two minutes carrying annotated structured data. Held at B because no accuracy figure, model card, named models or evaluation methodology for SimboAlphus itself was located, and because 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.

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 component business model creates two structural points a buyer should carry into diligence.

First, where this engine is embedded in a partner's product there are two retention questions rather than one, because a partner can make a clean commitment about its own environment while content is streamed to and held by this supplier under entirely different terms.

A clinician's deletion request may therefore reach one party and not the other, and nothing published establishes what persists on the supplier side after a response is returned, in what form, or whether derived artefacts such as quality scores and structured annotations are retained separately from the audio.

Second, a component supplier accumulates encounters from every partner deployment rather than from one customer base, which makes the unanswered training question more consequential here than for a single product vendor. One scoping caution belongs on this record and generalises to every multi product vendor in the index: encryption and privacy by design claims appearing in this company's material attach to a separate phone agent product, and a security claim is not transferable between products of the same vendor. A reader scanning a website will otherwise accumulate assurances that were never made about the thing they are buying.

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

A specific sourcing caution applies here more than to most entries in this index: Simbo 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.

No retention schedule, de identification practice or training use statement was located for this product.

The scoping caution from the earlier assessment stands and is worth keeping visible: encryption and privacy by design claims appearing in this company's material attach to its separate phone agent product, and this index does not transfer a security claim from one product 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 this axis 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. Establish what persists on this side after a response is returned, in what form, and whether derived artefacts 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.

Ask for the retention schedule, the training position in contract language, and what a downstream deletion request actually reaches.

No business associate agreement posture specific to this product was located, and 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 organisation 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.

That gives a buyer two questions rather than one. Ask the vendor you are contracting with whether any part of the speech or note generation is performed by a third party, and if so require that the subcontractor agreement be confirmed. Ask what happens to your data if that supplier relationship ends.

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, so establish whether personnel outside the United States can reach protected health information, in what circumstances, and how that access is logged.

One scoping caution carried forward: security claims appearing in this company's material for its separate phone agent product do not transfer to this one.

Ask for the agreement, the subcontractor position, and the offshore access model.

No named or dated attestation, no report of either type and no trust centre were located for this product.

What is published in their place is the phrase banking grade security. That belongs with the other constructions this index tracks as marketing rather than assurance, alongside military grade, enterprise grade, healthcare 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, and this is the fourth instance of that pattern in this lane. 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. A peer in this category states that point correctly in its own buyer guidance, which shows the distinction is well understood in the segment.

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.

Ask which report is held, of which type and period, and what scope it covers.

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 was located within it.

One feature of the interface offering bears directly on the reasoning that keeps products in this category outside device oversight, and it is unusual enough to record. 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.

That is more than most vendors in this lane provide, and the whole value of it 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. Ask this vendor what the score represents and how it is calibrated, and ask any product built on this engine whether it shows the score, at what threshold it changes the clinician's experience, and what a low score does.

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

No fairness statement, subgroup analysis, accent or dialect performance disclosure, or language coverage claim was located on the product materials.

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 best placed to 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 this axis stays unanswered across the category rather than a failing unique to one vendor. It also means a buyer's question should be redirected: ask a scribe vendor whether the speech model is their own, and if not, ask what accuracy evidence they have obtained from their supplier and across which speaker populations.

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. Naming the risk accurately and publishing no evidence about your own system is the pattern this index has now recorded several times, and the quality score the engine emits suggests the vendor already measures output quality in some form.

Ask what the quality score correlates with, whether it varies by speaker characteristics, and whether that has ever been examined.

One mechanism here is genuinely uncommon in this lane and it is the reason for the grade. The interface returns a quality score and metadata alongside each generated note, so an integrator receives a programmatic per note signal rather than an undifferentiated output.

That is a real transparency primitive: it lets a deploying product detect low confidence output and route it to human review instead of pushing it forward, which is the kind of control this axis credits, and it is the closest thing in the tail of this category to the published confidence thresholds this index rewards in coding vendors.

It also gives a customer something concrete to reason about after the fact, since a wrong note that carried a low score was flagged and a wrong note that carried a high one is a different kind of failure. Held at C because the score is a signal without a specification.

No accuracy figure, model card or evaluation methodology for the product itself was located, nothing states what the score means, how it is calibrated, or what threshold corresponds to what error rate, so an integrator receives a number without a key. The vendor's material also quotes generic industry accuracy ranges in close proximity to its own product in a way a reader could easily mistake for product performance, which is worth noticing rather than crediting. No warranty, indemnity or remediation commitment was located. Ask what the quality score is calibrated against and what threshold the vendor would defend.

API first rather than integration first, which is a different proposition and should be read as one. 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 an unusually wide client range including Linux, which almost nothing else in this category supports. Held at B because no named production EHR integration was verified: the specific systems mentioned in Simbo's material appear in generic category blog posts rather than on a product integration page.

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

The distribution model is the substance of this record and it should be stated plainly, because it changes how a reader should interpret this lane as a whole. The vendor sells its scribe technology as an interface and development kit, and names its partner categories directly: provider organisations, 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. This index catalogues many vendors in this category and they are not the same number of independent technology stacks. That is not a criticism of anyone. Component suppliers are normal and specialisation 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 practical instruction follows: ask any scribe vendor whether the speech and note generation are their own or licensed, and if licensed, from whom. Then ask the residency and retention questions of that supplier rather than only of the brand on the contract.

For this vendor specifically, ask where processing runs, given a stated presence in two countries, and whether the answer 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 genuinely unusual, spanning iPhone, Android, iPad and Mac, Windows and Linux desktops, which matters for clinicians on managed or non standard machines. Clinical coverage is not documented: no specialty count, specialty tuning claim, note format list or supported language list was located on the product materials.