OrbDoc

Ambient capture and structured documentation are the whole product. There is no practice management system, no record platform and no services layer underneath that would retain value without the models, and the company was built around the documentation capability rather than adding it to an existing product.

The speech layer is licensed rather than built, running on a named third-party medical speech model, with a cloud provider's artificial intelligence services and the vendor's own algorithms above it. Licensing the speech layer does not displace the model as the artifact being sold: the product is still the pipeline from conversation to structured note, and the vendor's own work sits in the structuring, the speaker separation, the specialty formats and the coding support around it. Naming the dependency rather than obscuring it behind a claim of proprietary technology is what distinguishes this from a reseller wrapping someone else's product.

The surrounding coding and billing toolset is rules-based reference material rather than model output, and it is offered free alongside the scribe rather than sold as the product.

The review gate is stated plainly and consistently across the vendor's materials: all notes are presented for provider review before they reach the record system, and the vendor describes the only change to the existing workflow as a quick review step before finalizing. Approval precedes the write rather than following it, which is the safer of the two orderings, because a note corrected after it has entered the chart leaves the original version in the record.

The audit trail supports the gate rather than substituting for it, recording when notes were created or modified and by whom, and recording which models were used for each documentation action.

One part is missing. Nothing published states the condition under which the system itself declines, flags low confidence or routes an encounter for closer attention. No acceptance rate, edit burden figure or confidence threshold is published, so nothing shows how much reviewing the gate actually requires. For a product whose value proposition is time saved, the acceptance rate is what determines whether the saving is real: a draft accepted with minor edits saves most of the time claimed, and one rewritten substantially saves very little.

The speaker separation feature bears on this. Encounters with several participants and family present are where attribution errors occur, and a note attributing a symptom to the wrong speaker reads as fluent and correct.

The suppliers are named. The speech model is given by product and version, Deepgram Medical Nova 3; the cloud and model layer is named as Google Cloud; and the vendor acknowledges its own algorithms on top rather than describing the system as proprietary and stopping there. Naming whose models are running makes the rest of the chain checkable.

The interoperability standard is named rather than gestured at: HL7 FHIR, stated explicitly rather than as integration generally.

The version and update discipline behind those names is missing. No model card is published, no accuracy figure or error rate is published, no evaluation methodology is described, and nothing states how or whether customers are told when a model in the stack changes. A named model with no change notification says what is running today and nothing about what will be running after the next release, which on a speech product is the difference that shows up as a shift in error patterns.

One published mechanism partly compensates. The audit trail records which models were used for each documentation action, so the model behind a specific note is reconstructable after the fact. That is retrospective provenance rather than forward notice.

The chain is named at every layer.

The vendor names its speech model by product and version, Deepgram Medical Nova 3; names the cloud and model layer it runs on, Google Cloud and its artificial intelligence services, with data stated to sit in that provider's compliant infrastructure; and acknowledges its own algorithms sitting on top rather than describing the whole system as proprietary. For an ambient scribe, naming the speech model matters more than naming a language model, because speech recognition is where accent, dialect and impairment cause errors that fall unevenly across patients, and a named model has published characteristics that can be researched.

The terms that govern content once it reaches those parties are also stated. The vendor says it maintains executed business associate agreements with all subcontractors who may access protected health information, naming the categories as the cloud infrastructure provider, the speech recognition service and the model provider. Audio is stated to be retained thirty days and then deleted, and the privacy policy states recordings are retained up to thirty days to improve the vendor's models.

One thing holds a buyer back from treating this as settled, and it is not an omission but a conflict. A product page states there is no persistent storage of audio after processing and that audio is immediately deleted after transcription. The privacy policy and the detailed retention schedule both state thirty days. Those cannot both be true, and the difference decides whether a recording exists to be disclosed, subpoenaed or used for model improvement.

No formal subprocessor list covering parties beyond the model layer is published, and nothing states whether customers are notified when a model in the stack changes.

Carefully structured, and still anonymous.

A cardiology group case study reports 45 minutes of daily time saved per provider, a 23 percent improvement in relative value unit productivity, and physician satisfaction rising from a 2.8 baseline to 4.2 out of 5 after six months. Quoting a baseline and a follow up interval states what was measured, against what, and over how long, which is what makes a figure checkable in principle. A telehealth deployment across 35 states with more than 800 contracted providers is also described.

None of it is attributable. No customer is named, no third party verified any of it, no study or controlled evaluation exists, and the satisfaction instrument is not identified. Well-presented vendor reporting is still vendor reporting.

One of those figures deserves separate attention rather than being read as a productivity result. A 23 percent improvement in relative value unit productivity is a coding and billing outcome, not a documentation one. It can arise from seeing more patients, from documenting existing work more completely, or from coding the same work at a higher level, and the three have very different implications. The case study does not distinguish them.

No accuracy or error figure for the documentation itself appears in any of the vendor's sources, and it is the measurement that matters most.

Retention, audio deletion and training use are all published, and one of them runs against the customer.

Retention is given specifically. Audio recordings are stated to be kept thirty days by default and then deleted automatically, with configurable extension to twelve months for teaching and quality improvement. Clinical documentation is retained ten years from date of service. Edit history is kept ninety days for version control. Automatic deletion after a specified period and legal hold are both offered as configurable policies.

Training use is the one that runs against the customer. The privacy policy says voice recordings are retained for up to thirty days to improve the vendor's models. Deidentified usage analytics are separately retained for system improvement. A clinician can request deletion at any time and delete recordings and transcriptions through the application.

So the position is not that customer content is walled off from model development; it is that it is used for it, within a stated window, with a deletion route. That is a legitimate posture and a candid one.

The vendor contradicts itself. A product page states audio is processed in real time and immediately deleted with no persistent storage. That cannot be true alongside a thirty day window used for model improvement. A commitment that cannot be relied on is not a commitment, however specifically it is worded.

A dedicated compliance page states that the company executes business associate agreements with all covered entity customers, and sets out what the agreement does: permitted uses and disclosures of protected health information, safeguard obligations, security incident and breach reporting, availability of records for access and amendment requests, availability of internal practices for regulator review, and return or destruction obligations on termination. It further states that executed agreements are maintained with all subcontractors who may access protected health information, naming the categories as the cloud infrastructure provider, the speech recognition service and the model provider. Downstream flow through is published here.

Retention is stated rather than left open: clinical documentation for ten years from date of service, audio recordings for thirty days and then deleted automatically.

The agreement itself is described rather than available. The instrument cannot be read before contracting, and no tier or edition is identified beyond covered entity customers generally.

One divergence matters. The vendor's short frequently asked questions page, which is where a clinician goes to ask, is asked directly whether the product is compliant and declines to answer yes, replying instead that it is built for healthcare documentation workflows and directing the reader to the privacy policy and terms. That page and the compliance page say different things about the same question. Where a vendor's own pages diverge, the operative version is whichever ends up in the contract.

Two claims need separating.

Data is stated to be stored in Google Cloud infrastructure configured for health privacy compliance. That certifies the platform the vendor runs on, not the vendor's own controls, processes or software. A well-certified platform hosting a poorly controlled application is precisely the failure an attestation exists to detect, so inheriting a provider's certifications answers a different question from the one a security review asks.

A set of operational controls is described, and they are specific: continuous monitoring of data access, anomaly detection on access patterns, quarterly review of access logs and permissions, automated generation of compliance reports, and regular security audits and compliance reviews described as ongoing process. Those are real controls stated concretely enough to be asked about.

What is absent is any named, dated artifact belonging to the vendor. No SOC 2 report of either type, no ISO 27001 certification, no independent penetration testing statement, no trust portal and no documented route to request a report appears anywhere naming the company itself. Described process is not an examination, and a health system review will ask for the report rather than the description.

One piece of the regional marketing measures something else entirely. Joint Commission International and the Saudi accreditation standards named on the Gulf pages are healthcare facility accreditation frameworks, not software attestations. A vendor aligning to them is describing the environment its customers operate in, not an examination of its own systems.

No clearance is claimed and none is required for ambient documentation. No United States device pathway attaches to a draft note the clinician reviews and finalizes, and the vendor is explicit that a review step before finalizing is the only addition to the existing workflow, which puts the signature exactly where the regulatory reasoning needs it.

The product is narrow in scope, and that narrowness is not a gap. The scope expansion common across ambient scribes, meaning coding engines that propose billing levels, real-time clinical insight, chart question answering, patient-facing products and revenue cycle modules, is largely absent. The closest approach is documentation described as linking evidence to support medical decision making and procedure coding, which is a claim about producing a defensible record rather than about proposing codes. That distinction carries weight: supporting the coding of what happened is a different object from optimizing toward the highest justified level.

The separate coding and billing toolset the company publishes sits outside the scribe and does not change this. A CPT database, an RVU calculator, a code validator, a bill analyzer and a bundling checker are reference instruments a coder operates, not a system proposing codes from an encounter, and the bundling checker in particular exists to catch improperly unbundled claims, which runs against the revenue gradient rather than along it.

Keeping the product to documentation is a commercial choice, and it keeps the regulatory position simple.

Markets are the United States plus a marketed Gulf offering across six countries. The vendor describes no United Kingdom or European Union presence; ambient documentation is treated as software as a medical device in those markets, so a move there would require reassessment. The Gulf position is a separate question, since device and health data rules differ by country there.

The vendor publishes nothing on how model behavior is governed and tested: no fairness or subgroup evaluation with a stated method, no independent assessment, and not even a governance framework with a named process behind it. No subgroup data, no accent or dialect performance breakdown, no evaluation methodology, and no independent review of model behavior.

What is published is a commitment rather than evidence, and it is aimed at the right failure mode. The vendor states that its speaker separation is trained on diverse accents and speech patterns common in healthcare settings. That is an affirmative claim about the training set directed at exactly the error that falls unevenly across patients. It is asserted and not demonstrated.

The gap matters more here than it would elsewhere because of the product's stated reach. The vendor markets a Gulf offering with native Arabic support alongside its English-language markets, and speech recognition quality across languages and accents is precisely the property it is selling. A vendor charging for performance in a second language has the strongest reason to publish how that performance was measured.

What the vendor does publish on monitoring is compliance surveillance rather than model governance: continuous monitoring of data access, anomaly detection on access patterns, quarterly review of access logs and permissions, and automated compliance reporting. Those are controls over who touched the data, not over how the model behaves.

One mechanism here is strong for investigating a note after the fact. The audit trail records which models were used for each documentation action, alongside who accessed what and when. When a note is disputed months later, the log shows what produced it and on which model version, rather than leaving the organization to reason about the product in general. That is the evidence any correction, complaint or internal review would actually need, and the log reaches past user actions to the model itself.

Against that, the vendor's published statements contradict each other on a basic question, which is a defect in its own right rather than a gap. A product page states that audio is processed in real time and immediately deleted with no persistent storage. The privacy policy states that voice recordings are retained for up to thirty days to improve the vendor's models. A detailed retention schedule elsewhere on the same estate gives thirty days for audio as a default with configurable extension to twelve months. Those are three answers to one question, and they differ on both the period and on whether recordings are used for model improvement at all.

A buyer cannot rely on any of them, and the difference is material: it decides whether a recording exists to be produced under subpoena, disclosed in a breach, or used to train a model. Where a vendor's own pages disagree, the operative version is whichever ends up in the contract, so that is where the question belongs.

Nothing stands behind the output. No accuracy or error figure, no published limitations and no warranty, indemnity or remediation commitment exists, and no route is described for a patient who finds an error.

The problem here is a direct contradiction inside the vendor's own site rather than an absence.

The integration landing pages describe named, standards based, bidirectional exchange over HL7 FHIR across clinical, administrative and revenue cycle modules for Allscripts Sunrise Acute Care, TouchWorks, Professional and Veradigm, supporting both cloud hosted and on premise deployments, plus direct audio capture from Zoom for Healthcare, Microsoft Teams for Healthcare and Doxy.me.

The vendor's own support material describes a mobile application, and the application store listing describes export to major record systems including Epic, Cerner and athenahealth. Export is not write-back, and a mobile application does not perform bidirectional exchange with an on-premise Allscripts Sunrise Acute Care instance. The capability may well exist for enterprise implementations, but marketing pages that the vendor's own product documentation contradicts do not show it.

The pages follow a familiar pattern: a page per record system, each describing deep integration, which suggests they were generated for search rather than reflecting a built connector. The tell is that the depth described is identical across every system named, which is not how integrations are actually built, and that no single named deployment appears on any of them.

What is established is that the note leaves the product and reaches the chart somehow, and that the standard is named rather than gestured at.

Nothing published shows which mechanism actually runs for a given record system, names a site running the bidirectional path in production, or says whether the platform is available beyond mobile. The product surface described in support material and the one described in the integration pages are not obviously the same product.

The hosting platform is named and the location is not.

Google Cloud is stated as the infrastructure, configured for health privacy compliance, and processing is described as occurring on the vendor's servers. No region, availability zone, residency option, tenancy model or subprocessor list is published, and nothing states which processing crosses a border. Naming a global cloud provider narrows very little on its own, because that provider operates in most jurisdictions.

The connectivity position is answered directly and resolves a claim that circulates about this product elsewhere. The vendor states that processing requires an internet connection, and describes limited offline behavior rather than offline operation: a recording can be captured without connectivity and is queued, previously generated notes can be edited offline, and saved notes can be viewed, but the note is produced once the device is back online. Third-party material describing this product as having an offline-capable architecture that generates notes without connectivity is contradicted by the vendor's own documentation and should not be relied on.

The regional question is larger here than for a single-market product. A Gulf offering is marketed across six countries alongside the United States business, and several of those markets have their own expectations about where health data may rest. Nothing published states whether regional infrastructure exists or whether all processing returns to the same place.

Delivery is a mobile-first application with cross-device continuity between phone and tablet.

No rate card, tier structure or per-provider figure is published for any market.

What is discoverable is the posture rather than the cost. The vendor operates a freemium model on the application store, stating that core transcription stays free while premium features are introduced as paid additions, and it promotes a free trial prominently. So a clinician can see how the product is sold and can start using it without a conversation.

What cannot be established is what anything costs once the free tier is outgrown. Which capabilities sit behind the premium boundary, what the paid rate is, and whether enterprise deployment is priced per provider, per site or per encounter are all unpublished.

That gap matters because of who the vendor sells to simultaneously. The same product is marketed to integrated delivery networks and academic medical centers at one end and to rural single-site hospitals, small practices and solo clinicians at the other, with a rural hospital testimonial describing it as advanced documentation at an accessible cost. Accessible relative to what is exactly the question a published anchor would answer, and the buyer least able to run a procurement process is the one most dependent on it.

Wide across settings, and across regions too.

Coverage spans emergency departments, inpatient services, ambulatory clinics, cardiology, pediatrics, family medicine and mental health, sold to integrated delivery networks and academic medical centers at one end and to rural hospitals, small practices and community care teams at the other. Cross-device continuity is part of the design, so a note started on a phone during rounds is finished on a tablet at the nurses' station, which suits the inpatient settings named better than a desktop product would.

The distinguishing element is geographic. The vendor publishes a dedicated Gulf offering with native Arabic support and alignment to Joint Commission International and Saudi accreditation standards across Saudi Arabia, the United Arab Emirates, Qatar, Kuwait, Bahrain and Oman. Arabic clinical documentation is a materially different problem from adding a language to a menu: the script, the dialect variation across those six markets, and the code-switching between Arabic and English that is normal in Gulf clinical practice all bear on recognition quality.

Two things temper that breadth. The settings and regions above are named on the vendor's marketing pages, which on the integration question describe capability the vendor's own product documentation does not support. The same pages are the source here. And nothing published names a deployment, a site or a customer in any of the settings or countries listed, so breadth is claimed rather than evidenced.

No recognition performance figure is published for Arabic or for any other language.