Skriber

Ambient capture and note generation are the entire product with no services business underneath. The human prompt engineering team is an onboarding function that configures the model for each customer, not a delivery workforce producing the output.

Conventional draft and review with a real time element: the note builds during the encounter and is presented ready to sign for clinician review rather than filed automatically, and transfer into the record is a deliberate clinician action. No edit burden figure or confidence threshold is published, and the acceptance figure the vendor states carries no method, which matters more given the independent review noting incomplete diagnosis capture.

There is no accuracy figure, model card, named models or evaluation methodology, and two claims cannot be tested at all. Skriber describes itself as the number one AI medical scribe and states that its system delivers the most accurate billing codes of any AI scribe on the market. Neither is measurable, and neither cites a comparison. The company competes specifically on coding accuracy and publishes no coding accuracy result.

No party in the chain is named, but the architecture is described.

What is published: ambient listening with natural language processing, a proprietary de-identification algorithm applied during capture, a model described as adapting to each clinician's tone and structure, and a bespoke onboarding stage in which engineers tune output. A reader can follow how a consultation becomes a note.

What is not published is who else touches it. No model or model family, no foundation model provider, no hosting arrangement and no subprocessor list. One phrase invites a more generous reading than it earns: the vendor refers to our model. That is marketing possessive rather than a disclosure, and it does not establish an in house build. A licensed engine sold as a feature is described the same way, and nothing on the site tells the two apart. The distinction matters because an in house chain would be a materially better answer here than a silent one.

The human access surface is the distinctive risk here, and an easy one to overlook. Onboarding is bespoke and staffed. The vendor states that prompt engineers work with each new customer to configure note output, that every new physician works directly with an engineer to match their personal documentation style, and that difficult specialty templates escalate to a named clinician at the company. The stated objective is to hear the physician's voice in order to replicate their style of writing. Replicating a writing style requires examples of that writing, and tuning output requires seeing notes, so the natural reading is that named individuals at the vendor see real clinical documentation during setup. Clean alternatives exist that would achieve the same result, including synthetic samples or the physician's own prior notes with identifiers removed, and nothing published says which is used.

No study, controlled evaluation, accuracy benchmark or named institutional customer is published. What does exist is third party review presence across several independent software directories and app stores, which is worth more than a curated testimonial page because the vendor does not control it.

The feedback there is mixed rather than uniformly positive, including a reviewer rating the product eight out of ten with adjustments still needed for their practice, and at least one user reporting that spoken diagnoses were not fully captured. Mixed independent reviews are a more useful signal than a perfect one, and the negative note about incomplete capture is the specific thing to test in a trial.

Health privacy compliance is asserted and the product is described as ready for the European regulation, but nothing published sets out a retention schedule for audio or transcripts, a deidentification practice, or whether customer content trains models.

One unusual feature is confirmed in the vendor's own words rather than left to inference.

Onboarding is human and bespoke. The vendor states that a team of prompt engineers works with each new customer to configure note output, that every new doctor works directly with an engineer to match their personal documentation style, and that where an engineer cannot configure a specialty template the case escalates to a named clinician at the company who adjusts it himself. The vendor describes the objective as hearing the physician's voice in order to mimic and replicate their style of writing.

That is a considered approach to a real problem, and it also opens a human access surface. Replicating a physician's writing style requires examples of that writing, and tuning note output requires seeing notes. So the question is direct: during onboarding, do named individuals at the vendor read real patient encounters, and if so under what controls, with what logging, and with what consent from the patients whose encounters they are.

There are clean answers available. Synthetic or de identified samples, or the physician's own prior notes with identifiers removed, would achieve the same result. Nothing published says which is used.

The business associate agreement is published in full and binds every user of the platform. Skriber's Platform Terms of Use, last updated 9 October 2024, state that protected health information in customer data is processed in accordance with the Business Associate Agreement attached as Schedule A, that providing data binds the customer to it, and that where the terms and the agreement conflict the agreement controls for protected health information. Schedule A is on the same page, readable before signup.

The agreement is incorporated into the terms every user accepts, so no tier or plan runs without it, the self serve product included.

The agreement discloses that it reaches subcontractors: the business associate must ensure that any subcontractor to whom it provides protected health information agrees to the same restrictions and conditions, and return or destruction obligations extend to information held by subcontractors and agents. The agreement leaves open which parties those are.

One inconsistency concerns the contracting entity. The Platform Terms of Use are an agreement with Skriber LLC under Washington law, while Schedule A names Skriber, Inc. as the business associate. Nothing on the page reconciles the two names.

The homepage names an attestation.

Under its key features the vendor states that it is ISO 27001 compliant and certified. That is a recognized information security standard rather than a description of controls, and naming it is the strongest point. What is absent is the artifact and everything that gives the claim meaning: no certificate number, no certification body, no statement of scope, no issue or expiry date and no portal a buyer can open. A certification has a scope and a clock, and neither is checkable here. Scope matters more than it sounds: an ISO 27001 certificate covers a defined boundary, and a certificate covering corporate IT is a different thing from one covering the system that processes consultations.

Another claim in the same block is inaccurate, and it bears on how much weight the first one carries. The vendor states that it is HIPAA compliant and certified. There is no HIPAA certification. No body issues one, and compliance with that statute is a contractual and operational posture rather than an award. Publishing a certification claim for something that cannot be certified weakens the neighboring ISO claim, which is made on the same footing and with no certificate behind it.

The onboarding model gives the missing artifact a specific shape rather than a generic one. The vendor's differentiator is that named engineers work directly with each new customer to configure note output, escalating to a clinician at the company where a specialty template proves difficult. Human involvement of that kind is precisely what an independent examination exists to describe: who at the vendor can reach customer content, under what authorization, whether that access is logged, whether it is time bound to the onboarding period, and what happens to the material afterward. A vendor whose model depends on staff access carries a heavier disclosure burden than one whose pipeline is fully automated, not a lighter one.

The European readiness claim raises the same doubt. That regulation requires demonstrable technical and organizational measures, and readiness is a self assessment.

No clearance claimed and none required for ambient documentation. No device pathway attaches to a note the clinician reviews and signs, and the vendor is explicit that the physician is the one who signs the note rather than the company.

The product is narrow in scope. Ambient capture, dictation and templates produce a note; billing code generation is present but framed around reimbursement accuracy and reduced claim rework rather than revenue lift. No risk adjustment scoring, no decision support layer, no patient facing component and no order generation appear within it. The product has not extended into adjacent clinical or financial territory, where a regulatory question would follow.

One feature of the design bears on what the signature means. The vendor's stated objective is to mimic and replicate each physician's own writing style, tuned by engineers during onboarding, so that output reads as that clinician wrote it. The rationale given is sound: the doctor signs the note, so it should sound like the doctor.

It also removes a signal. Where generated text is stylistically indistinguishable from a clinician's own writing, nothing in the finished record indicates which passages were drafted by a system and which were composed by the person signing. That is not a regulatory problem today, and it matters for anyone later reviewing that note in a complaint, an audit or a claim, and for institutions that expect to identify AI assisted documentation in their own records. A published figure of 98 percent first pass acceptance sharpens the point rather than softening it: the less a clinician edits, the more of the signed record is machine composed and unmarked.

The site carries no fairness statement, subgroup analysis or accent and dialect performance disclosure, and no language coverage is claimed, which is at least internally consistent since the product does not market multilingual capability. Billing code generation is framed as reimbursement accuracy and reduced claim rework rather than revenue lift, which sits at the mild end of how ambient scribes present coding.

Two things about how this vendor makes quantified claims bear on every unevidenced statement on the site, not on bias alone.

The headline time saving figure differs between the vendor's own pages. Several state one range and another states a figure roughly two and a half times higher for the same product and the same claim. A number that varies that much across a vendor's own material is not a measurement; it is a choice. That does not make the product worse, and it does mean an unevidenced figure from this source should not be carried into a business case.

The accuracy language goes further. The site describes the product as transforming raw patient data into perfectly accurate notes. No speech recognition and generation system can support perfect accuracy, third party reviews report users citing inaccurate summaries, and another ambient scribe vendor explicitly repudiates this kind of claim on a published page arguing that overclaim erodes trust.

That contrast is the useful one. A vendor that will assert perfect accuracy without evidence is a vendor whose silence on subgroup performance cannot be read as considered restraint.

A review gate and accuracy figures are published, and nothing stands behind either.

Review before commit is stated plainly. The homepage describes a note that only requires the clinician's final approval, and a draft generated for the clinician to review in real time before signing. Something stands between the model's output and the record.

Accuracy figures are published as well. The vendor states 98 percent note acceptance on first pass and 99 percent accurate SOAP notes. Neither carries a method. Acceptance is not accuracy: a note a clinician accepts is a note they did not choose to edit, which measures convenience and habit as much as correctness, and a busy clinician accepting a flawed note produces a high acceptance figure and a wrong record. The accuracy figure carries no denominator, no method and no reference standard, so there is nothing to check it against.

The comparative claims are weaker still. The product is described as the number one AI medical scribe and as delivering the most accurate billing codes of any scribe on the market. Both superlatives assert a win over rivals without publishing a measurement of any of them, so they claim more than a bare figure would while supporting less. The market leading claim is also circular in this instance: the vendor publishes its own comparison article ranking scribes, in which it places itself first.

Coding is where this matters most. A vendor competing specifically on coding accuracy publishes no coding accuracy result, and a wrong code shapes what is billed and creates false claims exposure for the practice submitting it. Nothing published characterizes where the coding output degrades or what checks it calls for before a suggested code is accepted.

Nothing stands behind any of it. No warranty, no indemnity, no remediation commitment, no stated limitations, and no route described for a patient affected by a wrong note.

Named systems, transfer level mechanism. Skriber lists DrChrono, Epic, Practice Fusion and eClinicalWorks among supported records and says it works with most EHR systems, but the described mechanism is that notes can be easily transferred into the record rather than written back into structured fields. A named logo and a bidirectional connection are not the same thing, and naming systems while describing transfer leaves the depth of each integration unstated.

No hosting region, residency option or subprocessor detail is published, and nothing establishes which model service processes the encounter or what it retains. Delivery is cloud with full functionality claimed across desktop, tablet and mobile.

Residency is not an idle question here. The vendor claims readiness for the European data protection regulation alongside the United States rule, and that regulation imposes conditions on where personal data is processed and on transfers outside the region. A vendor asserting readiness for it while publishing no hosting region has claimed compliance with a framework whose first practical question it does not answer. Nothing says whether a European deployment is processed in region, or whether that differs from the default.

One integration detail is honest. The vendor names integrations with three major record systems and states plainly that the depth of integration depends on access permissions at each hospital or clinic. That is true of any integration. What a demonstration shows may not be what a given institution's permissions allow, so integration depth depends on the customer's environment rather than a product specification.

It also leaves the mechanism unstated: nothing says whether the connection is a certified interface, a marketplace application or an extension, which determines whose identity its writes carry and how they appear in the audit log.

A free trial is offered and promoted prominently, and a rate of roughly $149 per month circulates through third party review sites, but it does not appear as a price the vendor itself publishes, and one software directory offers to construct a personalized pricing breakdown, which suggests pricing is not straightforwardly published. The only number available comes from competitors and directories rather than the vendor.

Note formats are properly enumerated, covering SOAP, history and physical, discharge, intake, DAP and custom templates, which is more than several competitors specify and spans inpatient as well as outpatient structures. Documented users include urgent care and residents in training. Against that, it publishes no specialty count, no specialty tuning claim and no language coverage, so breadth is hard to judge. Specialty fit here is achieved through the prompt engineering onboarding rather than through pre built specialty models.