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, so the moat is not the model.

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 full autonomy for documentation, and no confidence threshold, acceptance rate, review gate or accuracy figure is published for it. The AI Revenue module automating billing and coding compounds the question rather than answering it.

What produces the output is named rather than gestured at. Beam publicly stated that its artificial intelligence features were built on OpenAI models, and it publishes developer documentation describing the integration concretely, down to the number of endpoints required to autoscribe a consultation and post the note to the record.

The supplier is named. The discipline is not.

Four things are absent. The disclosure dates from a 2023 announcement covering earlier features rather than a current statement about the shipping scribe, so it identifies a lineage rather than a current architecture. No model version or family is given. No update or change notification practice is published, and that practice is what would tell a customer when the system they validated stopped being the system they are using. And no model card, evaluation methodology or accuracy figure is published.

The staleness matters because the naming is the whole of the disclosure. A vendor whose transparency rests on one sentence from three years ago is one silent model swap away from having none, and nothing published would tell a customer it had happened.

This vendor names its model provider, and the answer is checkable: it has publicly stated that its artificial intelligence features were built on OpenAI models.

Naming the model provider opens the dependency, the data flow, the provider's own published commitments and the exposure to a third party's policy changes to scrutiny, none of which is possible when a vendor calls its technology proprietary and stops. Developer documentation supports the disclosure with concrete integration detail, down to the endpoints required to produce a note and post it to the record, so the shape of the data path is inspectable rather than described.

Three things are missing. The statement dates from a 2023 announcement covering earlier features rather than a current statement about the shipping scribe, and a model provider named three years ago is not necessarily the provider in the product today. No subprocessor list is published. And no hosting arrangement is published separately from the model provider, so who holds encounter content at rest is unestablished even though who processes it is named.

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 is published.

One control here is engineered rather than promised. 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.

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

No retention schedule, deidentification practice or training use statement is published.

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

Beam publishes no named or dated attestation and has no trust center.

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.

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

The platform around it crosses several boundaries. 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 personalized 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. Nothing published says what that assistant is permitted to say, what guardrails constrain it, or whether any clinician sees its output.

Language translation between patient and clinician is a third function, and 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.

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. Against it, the company publishes no fairness statement, subgroup analysis or accent and dialect performance disclosure, 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. 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. 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. Nothing stands behind the output itself. No accuracy or error figure, no published limitations, and no warranty, indemnity or remediation commitment is published. The consent gate governs whether processing happens rather than what happens when the result is wrong, and those are different protections.

Named, varied and architecturally described. AdvancedMD connects through a one click toggle inside the Beam platform with consent gated data flow and automatic synchronization. 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 brittleness of robotic process automation. No certification program membership is published, and nothing independent confirms how deep each integration goes.

A named model provider is on record.

The company announced building its AI features on a named commercial general purpose model, covering note summarization, a patient facing chat assistant and language translation. Naming the provider is a real disclosure.

Three qualifications. The naming sits in an announcement covering specific features rather than in a current statement about the scribe, so it does not say 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 is published.

The vendor describes its integration architecture openly. 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, and it raises the same questions. Actions reach the chart through the user interface, and nothing published says whose credentials the automation runs under, how those actions appear in the record system's audit log, or 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.

There is no published rate card, tier structure or pricing model. 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. Dermatology appears through a named user. Translation extends reach to non English speaking patients. No specialty count, specialty tuning claim, note format list or supported language list is published.