Pabau

The artificial intelligence here is a module inside a platform whose main business is something else, and the vendor does not pretend otherwise.

Pabau Scribe is a real ambient documentation product, and it sits alongside booking, payments, inventory, marketing, photography, claims and reporting, most of which would function unchanged if the scribe were removed. The suite is if anything wider than a specialty record system, extending into point of sale, stock control of prescription injectables and marketing campaigns.

The pricing page settles the question directly: the scribe is listed as included on every plan at no additional charge rather than sold as a paid module. A capability given away with a subscription is a feature of that subscription, however good it is.

The company's own argument is a platform argument rather than a model argument: that documentation belongs inside the system that already holds the record, so patient data never passes to an external tool with separate governance obligations. That is a sound argument and it is about architecture, not about the model.

The platform now also markets voice and chat agents for reception, finance, marketing and sales as a paid add-on, which widens the artificial intelligence surface without changing what sits at the center of the product.

For a buyer the consequence is about roadmap rather than quality. A scribe that is a free feature of a practice management subscription is developed on that platform's priorities, and a clinic wanting the deepest documentation product available is buying a different kind of thing.

The oversight step is published explicitly rather than left to be assumed: notes are generated ambiently and reviewed by the clinician before entry into the record. Stating the review point in product material rather than in a policy makes it checkable, and it puts approval before the write rather than after, which matters because a note corrected once it is in the chart leaves the original version behind.

Role based permissions add a second layer and are described concretely rather than in the abstract: reception staff can book appointments and take payment but cannot edit clinical notes. Separating administrative from clinical write access is the control that keeps a shared front desk login from becoming a clinical one.

The review itself is undescribed. Nothing states what the reviewing clinician is shown, whether generated text is visually distinguishable from what the clinician wrote or dictated, whether low confidence passages are marked, or what happens to the underlying recording once the note is approved. A review step is only as good as what it surfaces, and a draft that reads uniformly fluent gives a reviewer nothing to catch on.

No acceptance rate, edit burden figure or confidence threshold is published.

The specialty context sharpens this. In aesthetic consultation the same phrase can describe anatomy or a product quantity, so the passages most likely to be wrong are precisely the ones a fluent draft will not flag.

No model, architecture or training description is published, and no accuracy figure of any kind is offered for the scribe.

The specialty tuning claim is the part a buyer would most want evidence for. Aesthetic consultation language is ambiguous in ways general transcription handles badly, since the same phrase can describe anatomy or a product quantity, and configurable specialty templates are a formatting feature rather than evidence that the underlying recognition handles that ambiguity. Nothing published distinguishes the two.

A data processing agreement is published with subprocessors and security measures listed, so who else touches the data can be seen without asking.

It is accompanied by an explicit and correct allocation of roles, with the clinic named as data controller and the vendor as processor. That allocation determines who carries the obligations to the patient. Encryption is stated at a named strength rather than as bank grade, and audit trails cover every clinical record interaction.

One entry is not established: whether a foundation model provider appears on that published subprocessor list. A model provider processing consultation content is a subprocessor like any other, and its presence or absence on the list is the difference between a complete chain and a partial one. The vendor's own design argument is that keeping documentation inside the platform avoids passing patient data to an external tool, which implies the processing may be in house, but implication is not disclosure.

Two further questions the document does not reach: retention of the underlying consultation audio once a note is approved, and whether any customer content contributes to model development. Neither is addressed anywhere on the vendor's site.

The platform also now markets voice and chat agents alongside the scribe, which is a second processing path and may involve different parties again.

Adoption is stated at more than 4,000 healthcare practices worldwide. That is a real commercial fact and it is not evidence of benefit: it establishes that clinics buy and keep the platform, which speaks to switching costs and serviceability rather than to whether the documentation is accurate.

The only quantified claim published is a reduction in practice management overhead of up to 60 percent. A figure expressed as up to sets a ceiling rather than reporting a result, and it is unfalsifiable as written, since any outcome between zero and sixty percent satisfies it. It also measures the platform rather than the scribe.

Nothing else exists. No study, no controlled evaluation, no named customer measurement, no baseline, no denominator and no third-party assessment appears for the scribe or for the platform. Case studies are published on the vendor's site and name practices, but they describe workflow change rather than measured outcomes.

The absence that matters most is documentation accuracy. For a product whose output enters a clinical record and supports a claim, the relevant measurement is how often the note is right, and nothing published addresses it in any form.

The control detail is specific rather than generic. Protected health information is stated to be encrypted at rest and in transit using 256 bit encryption, with role based access controls, full audit trails of every clinical record interaction, and patient consent management tools.

Two further disclosures lift this above the norm. The company states plainly that the clinic remains the data controller and Pabau acts as processor, which is the correct legal characterization and one many vendors leave vague. And its data processing agreement, published with its subprocessors and security measures listed, means a buyer can see who else touches the data. What is not addressed is retention of the underlying consultation audio after a note is approved, or whether any customer content contributes to model development.

The vendor states a business associate posture.

In its own published material the company describes its platform as operating with a signed business associate agreement, and elsewhere sets out plainly that practice management software handling protected health information on a clinic's behalf is a business associate and that every such vendor needs a signed agreement. So the status is acknowledged rather than sidestepped, and the instrument is stated to exist.

It is supported by a substantive documentary position rather than a badge. Support for the United States privacy, security and breach notification rules is stated, a data processing agreement is published with subprocessors and security measures listed, the allocation of roles is explicit with the clinic as controller and the vendor as processor, and dedicated compliance pages exist for both the United States and European regimes. Dual coverage is a practical selling point for a clinic operating in both.

The agreement itself is not published, its scope is not described, and no tier is identified at which it applies. A statement that an agreement exists is not the same as an agreement that can be read before contracting.

The platform is described as having a one click compliance toggle. Presenting a regulatory obligation as a setting implies the platform can also run with it off, and nothing says what that switch changes, what the default is, or whether anything about the business associate position depends on it.

The vendor also publishes, in its own material, that health privacy law does not certify software and that compliant is self attested unless independently audited. That is accurate.

A dedicated trust portal exists, and it is candid about whose credentials it shows.

The portal presents a wall of credentials: a payment card standard attestation, a health privacy attestation report, an ISO 27001 certificate, a European operational resilience assessment, cloud security registry material and a privacy recognition for processors report. It then states directly that all of these belong to the cloud and data center providers hosting the platform, named as DigitalOcean and CoreSite, and that only the data protection registration is held by the vendor itself. That registration is an entry on a public register, not an audited certification.

So the vendor holds no independent attestation of its own controls, and it says so rather than letting the badges imply otherwise. Inherited certifications describe the building, not the tenant: a well certified data center hosting a poorly controlled application is exactly the failure an attestation exists to detect.

Labeling the inherited credentials as inherited is candid. It does not change what is assured, though it lends the vendor's other security statements more weight.

No examination of the vendor's own controls is published, though a dedicated security page and a separate trust portal both exist.

No device pathway applies and none is claimed. Documentation, scheduling and practice management software of this kind sits outside device regulation in both jurisdictions the company serves, and the published review step before a note enters the record puts the clinician where the regulatory reasoning needs them.

The regulatory surface that does apply is larger than a scribe alone would carry. The platform takes payments and runs point of sale, so payment card rules apply. It holds and tracks inventory of prescription injectables, so controlled product record keeping applies. It operates under two different data protection regimes at once. And it runs marketing campaigns to patients, which in several markets is separately regulated when the subject is a prescription-only medicine. None of that is device regulation and all of it is real compliance exposure that a buyer evaluating a scribe would not otherwise be thinking about.

The artificial intelligence surface has also widened beyond documentation. The vendor now markets voice and chat agents for reception, finance, marketing and sales as a paid add-on, with a cloud phone system and call handling. An agent that speaks to patients directly is a different object from a scribe that listens to a clinician, and the reasoning that keeps documentation outside device oversight does not transfer to it automatically.

The aesthetic setting adds one further question. Advertising and promotion of prescription-only cosmetic injectables to the public is restricted in the United Kingdom and in several European markets, and a platform generating patient marketing for clinics offering those treatments sits close to that line, though the obligation rests with the clinic.

Nothing published on model evaluation, subgroup performance or monitoring.

The exposure has a shape specific to this setting. Speech recognition accuracy varies with accent, dialect and first language, and this platform serves clinics across the United Kingdom, Europe and the United States, so the spread of speakers is wide by design. There is a second and less obvious dimension: an aesthetic consultation is a conversation about a patient's appearance, and a documentation model trained on that material is learning the descriptive vocabulary practitioners use about bodies and faces. What that vocabulary encodes, and whether the generated note reproduces it evenly across patients, is not addressed anywhere.

The vendor publishes an allocation of responsibility and ships consent tooling in the product.

It states plainly that the clinic is the data controller and it is the processor. That is not a courtesy but the allocation that tells a clinic where its obligations to patients actually sit, and vagueness on that point is how those obligations get quietly overlooked. It ships patient consent management tools, so consent is a function in the product rather than a paragraph in a policy, which matters because recourse begins with the recorded person having been asked. Audit trails cover every clinical record interaction, so a disputed entry has a history attached to it.

Nothing stands behind the output. No accuracy or error figure of any kind is published for the scribe, and no warranty, indemnity or remediation commitment is published. No route is described for a patient who finds an error in a note as distinct from a clinic raising it.

The specialty tuning claim is where evidence is most needed, and where an error would do its work. Aesthetic consultation language is ambiguous in ways general transcription handles badly, since the same phrase can describe anatomy or a product quantity, and a configurable template is a formatting feature rather than evidence the recognition resolves that ambiguity. A misrecorded unit on an injectable is a dosing error in a record a later practitioner will rely on.

Operating under United Kingdom and European data protection law, the recorded individual holds enforceable statutory rights including rectification, with a supervisory authority behind them and obligations reaching the processor as well as the clinic. Those rights come from the law rather than from anything this vendor undertakes.

The question inverts here, because this vendor is the record system rather than an application sitting on one. What matters is therefore what comes in, what goes out, and how hard it is to leave.

Public application interface documentation is published on an open documentation host. Application keys, webhooks, private apps, connected apps and an app marketplace are listed as included on every plan, with increased interface rate limits at the top tier. More than thirty named integrations are published, spanning payments, accounting, calendars, customer relationship management, analytics, video consultation and booking. Clinically relevant connections are named specifically: prescribing networks, a named pathology laboratory, laboratory ordering and results on every plan, electronic prescribing at the upper tiers, and fax throughout. A partner program invites third parties to build against the interface and list in the marketplace.

On the exit question the vendor publishes a data connector and dataset access at the top tier, which is the mechanism a practice would use to get its own records out in bulk. That is a partial answer to the portability concern.

None of it is evidenced in production. No customer is named against any integration, no marketplace listing is shown running at a specific practice, and the depth of each connection is not described, so it is unclear which are full two way exchanges and which are one directional pushes.

The consolidation pitch cuts both ways: one platform replacing several subscriptions concentrates the record, the billing and the marketing in one supplier.

Cloud only, and well documented because the subprocessors are named. Hosting is attributed to specific cloud and data center providers, and the data processing agreement lists subprocessors and security measures, so a buyer can trace where the data physically sits and who else has access.

Operating under both United Kingdom and European data protection law and United States health privacy law implies a residency answer exists for each market, since the same arrangement would not satisfy both. The specific regional split is not published, and no on premise or customer controlled option is offered or would be expected for a product of this kind.

A published pricing page sets out the unit, the tiers and an entry price, and stops short of figures for larger teams.

The pricing model is per user, with the unit stated plainly, charged per location except on the top tier which covers multiple sites. Five named tiers scaled by team size: Starter, Solo for a single user, Team for two to three, Medium for four to five, Group for six to fifteen and Enterprise for sixteen or more. Every tier includes the full platform, with the vendor stating explicitly that plans differ only by number of users and not by features. Unlimited patients on every tier except Starter, which caps at 100 clients. Monthly or annual billing with up to 20 percent saved annually. Prices are shown by region across five markets. An entry figure of $62 a month for a single user is published.

A full feature comparison matrix sets out the core platform against four optional add ons, so it is clear what sits inside the subscription and what costs more. That matters here because the scribe is inside it: the vendor lists its ambient documentation as included on every plan rather than as a paid module.

Two gaps remain, and the vendor states the first itself. Only the Starter and Solo figures are published; larger teams are told pricing depends on user count and add ons and are directed to a demo call. And there is no route to begin without that conversation: every call to action on the page books a demo, and no self serve sign up is offered.

The add on model is where cost becomes hard to predict. One add on is priced per location rather than per user and meters messages and artificial intelligence call minutes against a credit balance billed as used, which is a consumption charge on top of a subscription.

The product covers clinic operations: online booking, digital intake and consent forms and payments across the practice platform, with an add on of voice and chat agents for reception and finance.

Wide across private and elective outpatient practice rather than deep in one specialty.

Named settings include aesthetic clinics, medical spas, general practice, dermatology, cosmetic surgery, hair transplant, intravenous therapy, weight loss, mental health, wellness and gynecology, with multi location support coordinating clinicians, rooms and equipment across sites, and a stated base of more than 4,000 practices.

The clinical content is tuned toward injectables and aesthetic procedures, which is where the specialty templates and the injection plotting and body mapping tools point. That tuning is the real depth here: plotting an injection site onto a body map and carrying it forward between appointments is specific work that a general documentation product does not do.

Geographic coverage spans the United Kingdom, Europe, the United States, Canada and Australia, with the pricing page localized across five markets and the site published in five languages. Operating under two data protection regimes at once is a capability rather than a claim, since the platform has to satisfy both.

Two limits apply. It is the private pay sector throughout, with nothing indicating use in publicly funded or hospital settings, so the product is built for the economics of elective private practice. And the specialty list above is a marketed list; no deployment is named against any individual specialty, and the depth demonstrated in aesthetics is not demonstrated in the others.