Trace audio, context, cloud processing and storage before using voice typing in a clinical service.
Doctors considering Wispr Flow should start with a concrete information journey: what is captured, where it goes, what remains and who has authorised that use. A supplier's healthcare page is valuable evidence for that exercise. It cannot answer every question about a hospital's devices, contracts or intended clinical workflow.
This checklist uses Wispr's documentation checked on 4 November 2026 and relevant NHS England guidance. It is designed to help a clinician and their local team assemble a reviewable proposal. The outcome could be approval for a defined task, a request for more evidence or a decision to use a different service.
Describe the proposed use in one sentence
Begin with a specific statement, such as: "A clinician will dictate a reviewed letter into the approved correspondence application on a managed desktop." Identify whether any patient information is involved. A proposal for generic teaching emails has a different information flow from a consultation recording, even if both use the same account.
Add the product mode, account owner, device, application and working location. Specify what happens before and after dictation. Does someone prepare a source account? Is the output immediately visible for review? Who puts the final document in the record? These details turn a broad question about an AI brand into a decision about an actual service.
Keep the proposed scope narrow enough to evaluate. Approval for one document type should come with a clear description of that type, rather than becoming an informal licence for every feature added later.
Trace more than the spoken words
Wispr's enterprise privacy page describes optional context awareness that reads relevant text from the destination application while dictating. It also states that offline and non-US-residency deployments are not currently offered. These are material design facts for a clinical proposal.
Ask the team to trace the microphone input, contextual text, generated text and final destination separately. A clinician might avoid speaking a name while dictating beside an open patient record. The review still needs to establish what contextual input the configuration permits. Turning off a contextual feature is a setting to verify, not a substitute for documenting the rest of the journey.
Include secondary routes. A copied transcript, a screenshot attached to a support request or reusable text saved in a personal account can create another destination. The exercise should follow information wherever the proposed workflow puts it, including the ordinary actions people take when something goes wrong.
Separate training, storage and processing
Wispr’s healthcare-use guide requires the applicable signed BAA and specified data controls for PHI dictation. It now says Notetaker can work under a BAA, while other help pages retain blocking language. Confirm the covered mode, account settings and agreement directly before patient use.
Those are specific supplier requirements. The local review should separately establish retention and deletion arrangements for each data item. "Training disabled" answers a question about model improvement. It does not mean that audio never leaves the computer, that all history has been deleted or that every other feature shares the same retention rules.
Wispr's security overview describes US cloud processing, encryption in transit and at rest, and vendor-managed keys. It distinguishes dictionaries, snippets and feedback from dictated content. Its stated audit scope covers dictation, with Notetaker outside the relevant audit periods.
Use those distinctions to request exact evidence. If a service requires a particular retention period or location, obtain an answer covering the configured product and relevant processors. An attractive badge or a privacy switch is less useful than a document answering the service's actual requirement.
Make the UK decision locally and identify the jurisdiction
For ambient scribes, NHS England's professional guidance tells clinicians to check organisational approval and policies. It also addresses informing patients, dissent and checking generated notes. Its advice concerns ambient use for care; it should not be casually relabelled as a universal rule for all dictation everywhere.
The NHS England supplier registry explicitly places assurance and decisions with the local NHS organisation. A registry entry therefore cannot replace that organisation's assessment. Equally, an American BAA is not a decision that a particular UK service has authorised a particular tool.
In England, bring the proposed information flow to the relevant IT, information governance and clinical safety colleagues through the organisation's established route. Elsewhere, identify the responsible organisation and applicable local process. Keep the supplier's contractual assurances, the technical configuration and the organisation's use decision as separate records that can be checked against each other.
A worksheet for a reviewable proposal
This is a proposed blank worksheet, not evidence that Wispr has passed an assessment. Fill each row for the chosen mode and deployment. Where an answer is unknown, record an owner and the evidence needed rather than replacing it with an assumption.
| Item to trace | Question to answer | Evidence and decision to record |
|---|---|---|
| Microphone audio | What triggers capture, and can other voices be included? | Capture behaviour, intended setting and responsible reviewer |
| Application context | What surrounding text can be accessed in this configuration? | Enabled controls, permitted applications and verification date |
| Generated text | Where does the result appear before acceptance? | Destination field, review step and correction route |
| Local history | What remains on this device and under whose account? | Retention setting, device ownership and access controls |
| Cloud and processors | Where is each item processed or retained? | Current contract, processor evidence and retention requirements |
| Reusable content and feedback | Can text leave through snippets, exports or support actions? | Permitted content, support procedure and staff instructions |
| Final clinical record | Who checks, saves and retrieves the accepted document? | Named responsibility, correct-record check and failure procedure |
Add the proposed decision, its scope, the decision owner and review date below the table. Keep the evidence versions with it. This makes later changes easier to assess: a new mode, device or account may alter a row even when the supplier name stays the same.
Test the human workflow with fictional material
A technical and contractual review should be paired with an observable workflow. Use invented content to establish what the user sees before recording, how they stop capture and where text lands. Confirm that the real destination makes a final review possible. Check account sign-out and the transition between users on any shared workstation.
Rehearse a failure without patient information. For example, dictate a fictional administrative sentence into a permitted test field, interrupt the process and ask the user to recover it using the agreed method. The purpose is to reveal whether the procedure is understandable, not to manufacture a clinical accuracy score.
Keep a short incident route beside the instructions: whom to contact, what to stop and what information can accompany a support request. The route should make it possible to describe a fault without sending the sensitive content that caused concern. Record the end-to-end outcome, including where the accepted text was saved.
Keep knowledge work within its own information boundary
Sometimes reviewing a document exposes a general clinical knowledge gap. The question can often be formulated without moving the original patient account into another application. Removing a name alone may leave distinctive details; select only the information needed for the learning task and follow the receiving service's rules.
iatroX's methodology describes source-grounded clinical reference and structured reasoning. That makes it a useful destination for an appropriately framed evidence question, with sources available to inspect. It does not make a dictation tool's data arrangements interchangeable with iatroX's, or establish a shared clinical record.
A practical handoff is to write the general uncertainty in your own words, check that the question is suitable to send and then inspect the cited evidence. Documentation approval and reference use can support the same clinician while retaining clear, separately understood information journeys.
FAQs
Does switching off model training make Wispr Flow offline?
No. Model improvement, storage and processing are different questions. Wispr describes cloud processing; verify the configured retention and contractual arrangements separately.
Does a Wispr BAA approve its use in an NHS service?
No. It is a supplier healthcare agreement, not the local organisation's decision. The service still needs to assess the intended workflow through its own processes.
Can a clinician use Notetaker under the same BAA?
Wispr’s current healthcare guide says Notetaker can work under a signed BAA, but its security and Notetaker pages retain conflicting restrictions. Confirm the feature and agreement with Wispr; do not extend dictation arrangements to recording by assumption.
For the separate knowledge task, explore how iatroX works, and take a completed data-flow worksheet to the colleagues responsible for approving your clinical workflow.