Beam Health

The AI arrived after the business did. Beam was a telehealth and virtual workstation platform covering video, scheduling, payments, patient registration and marketing, and the company describes its move into auto scribing as a pivot into uncharted territory rather than its founding purpose. Strip the AI modules out and a functioning telehealth business remains, which is the moat is not the model pattern applied in this category to Conveyor AI, Chartnote, iScribeHealth and Playback Health.

The marketing sells the absence of a review step rather than describing one. Charting is presented as completing in one click, notes are pushed to the record, and the developer documentation states that the API can create SOAP notes, look up billing codes and post them automatically to the EHR.

Automatic posting through an API is the furthest end of this category's autonomy range for documentation, and no confidence threshold, acceptance rate, review gate or accuracy figure was located for it. The AI Revenue module automating billing and coding compounds the question rather than answering it.

Graded up for answering the question this index now puts to every vendor in the lane: whose model is it. Beam publicly stated that its AI features were built on OpenAI models, which almost nobody else in this category discloses, and it publishes developer documentation describing the integration concretely, down to the number of endpoints required to autoscribe a consultation and post the note.

Held at B because that disclosure dates from a 2023 announcement covering earlier features rather than a current statement about the shipping scribe, and because no accuracy figure, model card or evaluation methodology was located.

This vendor answers the question this index puts to every company in the lane, and very few of them answer it: it has publicly stated that its artificial intelligence features were built on a named model provider's models. Naming the provider lets a buyer reason about the dependency, the data flow, the provider's own published commitments and the exposure to a third party's policy changes, none of which is possible when a vendor calls its technology proprietary and stops.

Developer documentation supports it with concrete integration detail, down to the endpoints required to produce a note and post it, so the shape of the data path is inspectable rather than described. Held below the top grade for a specific and important reason a buyer should check before relying on the disclosure.

The statement dates from a 2023 announcement covering earlier features rather than a current statement about the shipping scribe, and a model provider named two years ago is not necessarily the provider in the product today. Model layers get swapped without announcement more often than they get announced. No sub processor list was located either, and no hosting arrangement is published separately from the model provider. Ask whether that provider is still in the path for the current scribe, and for a sub processor list with change notification.

Named clinician testimonials including a dermatologist and a group practice principal, alongside vendor claims of two hours returned daily, hundreds of thousands in annual savings and users increasing revenue by 79 percent annually. None carries a denominator, cohort or method, and the revenue figure describes the whole platform including marketing and patient acquisition rather than the scribe. No study, controlled evaluation, accuracy benchmark or third party rating located.

One control here is engineered rather than promised and deserves credit. On the AdvancedMD integration the vendor states that patient consent is required and that no data is transmitted without it, which makes consent a gate on transmission rather than a policy statement, and it is one of very few consent mechanisms located anywhere in this wave.

Asynchronous telehealth content is protected behind authenticated links and two factor authentication.

Held at B because no retention schedule, de identification practice or training use statement was located.

HIPAA compliance is stated consistently across the platform and its video, payments and messaging components. Business associate agreement terms are not published for inspection.

No named or dated attestation for this vendor, and no trust centre, was located in a second pass.

One attribution needs restating so it is not misread. The vendor's AdvancedMD partner page describes that partner as HIPAA compliant and holding SOC 2 Type II. That certification belongs to the integration partner. It says nothing about this vendor's own systems, and a buyer reading the partner page could easily take it the other way.

The absence carries more weight here than it would for a single product vendor, for the same reason it does at Glass Health. This company sells an application programming interface and a software development kit, and publishes documentation showing how another company can build autoscribing into its own product using these endpoints. A developer buyer does not merely trust this vendor. It inherits this vendor's posture into its own product and passes it downstream to the practices and patients that product serves. Subprocessors, retention and access controls are more load bearing for a platform sold to builders than for one sold to a single clinic.

The product surface is also wider than a scribe. Named modules cover intake, documentation, revenue, growth and information technology support, so an assessment scoped to the scribe alone will understate what a contract actually reaches.

Ask which report this vendor holds in its own name, of which type, covering which period, and which modules and endpoints fall inside its scope.

No clearance claimed and none required for ambient documentation. The base position holds for the scribe itself.

The platform around it crosses several boundaries, and one of them is unusual for this category. Alongside note generation the product looks up billing codes and posts notes to the record system automatically, which is the reimbursement boundary plus an action rather than a suggestion.

The sharper item is a patient facing assistant. The company describes offering patients around the clock access to a virtual healthcare assistant that answers questions and provides personalised health information, built on a named commercial general purpose model. Two things compound there. The reasoning that keeps clinical decision support outside device regulation depends on a professional being able to review the basis of an output, and a patient asking a chat assistant at two in the morning is not a professional and has no reviewer. And a general purpose model is not built for clinical safety, so the usual mitigation of domain tuning is absent as well. Establish what that assistant is permitted to say, what guardrails constrain it, and whether any clinician sees its output.

Language translation between patient and clinician is a third function worth naming, because it is safety relevant in a way that is easy to miss. A translation error inside a clinical encounter changes clinical meaning rather than producing an awkward sentence, and neither party is positioned to catch it, since each understands only one side of the exchange.

Markets appear to be United States only.

Ask which modules are in contract, because the scribe, the coding function and the patient assistant carry different regulatory conversations and are sold on one platform.

One language access capability, no governance disclosure. Beam ships a translation feature intended to let patients and providers communicate across language barriers, which extends access beyond the note itself, and that is worth crediting. Against it, no fairness statement, subgroup analysis or accent and dialect performance disclosure was located, and the AI Revenue module automates billing and coding without any published accuracy or oversight description. The 79 percent revenue claim is platform wide rather than coding specific, so this sits below the coding gradient's aggressive end rather than on it.

One mechanism here is engineered rather than promised, and it is uncommon enough in this wave to carry the grade. On the record system integration the vendor states that patient consent is required and that no data is transmitted without it, which makes consent a gate on transmission rather than a paragraph in a policy. That matters on this axis specifically.

Almost every product in this lane treats consent as the clinician's problem, disclaims responsibility for obtaining it, and proceeds regardless; a system that will not move content until consent exists puts the recorded person into the process rather than around it, and recourse begins with the affected person having been asked.

Asynchronous content is additionally protected behind authenticated links and second factor authentication, which bounds who can reach output after it is generated. Held at C because nothing stands behind the output itself. No accuracy or error figure, no published limitations, and no warranty, indemnity or remediation commitment was located. The consent gate governs whether processing happens rather than what happens when the result is wrong, and those are different protections. Ask what the vendor commits to when a note is wrong, and confirm the consent gate applies across every integration rather than the one where it is documented.

Named, varied and architecturally described, which is more than most. AdvancedMD connects through a one click toggle inside the Beam platform with consent gated data flow and automatic synchronisation. Healthie connects through a Chrome extension sending the generated note to the patient chart in one click.

Beyond fixed integrations, an API and SDK let other platforms embed the scribe directly, and the company has written publicly about building an auto scribe against a DOM based EHR integration, which is browser level interaction rather than a sanctioned data channel and carries the same brittleness this index notes for robotic process automation. Held at B because integration depth per system was not verified and no certification programme membership was located.

Better established than previously recorded. The dependency the earlier note flagged is now named.

The company announced building its AI features on a named commercial general purpose model, covering note summarisation, a patient facing chat assistant and language translation. Naming the provider is a real disclosure and is credited, since most of this category leaves a buyer to infer whether encounter content leaves the vendor's environment at all.

Three qualifications. The naming sits in an announcement covering specific features rather than in a current statement about the scribe, so a buyer should confirm what processes the encounter today. Nothing published states what that provider retains, for how long, or under what enterprise terms. And no hosting region, residency option or subprocessor list was located.

The integration architecture deserves separate attention, and the vendor describes it openly, which is to its credit. Its own engineering write up explains that notes are inserted into the record system by manipulating the page in the browser rather than through an interface built for the purpose. That is the same class of approach as robotic process automation elsewhere in this lane and it raises the same questions. Actions reach the chart through the user interface, so establish whose credentials the automation runs under, how those actions appear in the record system's audit log, and whether the permission model that constrains a human user constrains it equally. The vendor also notes the approach is fragile against changes in the host system, which is a maintenance risk alongside a control one.

Ask for the current model provider, its retention terms, the hosting region, and the credential model behind the browser integration.

No published rate card, tier structure or pricing model located. Access runs through a demo and a signed contract, and partner documentation refers to fees due to Beam without stating them. Because five modules are sold both together and separately, a buyer cannot determine what the scribe alone would cost.

Telehealth native rather than specialty defined, covering live video consultation and asynchronous store and forward encounters where a patient submits an intake form and the clinician replies with a recorded video, which is a documented encounter type almost nothing else in this category addresses. Dermatology appears through a named user. Translation extends reach to non English speaking patients. Held at C because no specialty count, specialty tuning claim, note format list or supported language list was located.