A shared computer does not have to mean a shared clinical identity. The confidentiality problem arises when the next person can see the previous user's conversations, continue their session or act under their name. For clinical AI, the review must include saved prompts, drafts, exports and connected permissions, not simply whether the workstation has a password.
Separate the device, application and clinical record identities
A workstation login, a browser session, an AI account and a clinical-system identity are not necessarily the same thing. Logging out of one may leave another active, depending on the configuration. A deployment should therefore test the complete handover rather than assume that one visible sign-out ends every session.
This is especially important when the AI can call another application. The person visible at the computer may change while a delegated process continues under an earlier authorisation. The team needs to know which actions remain pending and how the next user is prevented from accidentally adopting them.
As checked on 10 October 2026, the GMC's record-keeping standards require records that identify who created them and when. That professional requirement supports identifiable clinical work; it does not mean a software audit entry alone proves who reviewed every statement.
Walk through a fictional room change
Imagine a fictional clinic where a doctor leaves a consultation room and another clinician starts using the same workstation. The AI application remains open on a previous conversation. A draft contains clinical details, while a connected workflow is still preparing correspondence.
Several questions now need separate answers. Can the second clinician view the conversation? Can they edit or send the draft? Will their actions be attributed to the first user? Is the pending task still attached to the correct patient and responsible person? Does locking the screen pause the visible interface only, or affect the connected workflow as well?
The problem is not solved by telling staff to be more careful. A practical implementation should make the transition understandable and testable. The next clinician should encounter a clear, authenticated starting state rather than inherit whatever the previous person left behind.
Give individual users a workable route
Shared credentials can obscure accountability and make selective access changes difficult. A proposed account model should provide identifiable access for permanent staff, rotating trainees, locums and other authorised users without forcing unsafe workarounds when a new colleague arrives.
The organisation should agree who provisions accounts, how roles are checked and how access is removed. Temporary staff need an appropriate route that works during the actual service hours. Otherwise, a technically strict policy may coexist with informal password sharing because the approved process cannot support the clinic.
Fast access and secure access are not necessarily opposing goals. The design question is how an approved authentication and session-management process can fit the clinical workflow while preserving individual identity. The NIST zero-trust publication, published in 2020, provides a general foundation for checking access to resources rather than treating device location as sufficient trust.
Treat conversation history as a separate information store
Even when an AI is not connected to the electronic record, saved conversations can reveal clinical concerns, professional activities or sensitive contextual information. A browser history, recent-file list or downloaded export can create another route to that material.
Ask what persists after the visible conversation closes. Determine whether history is account-specific, whether exports remain on the shared device and whether support or recovery workflows expose saved content. Do not assume that deleting a browser tab deletes information held by the service.
The same scrutiny applies to reference and learning products. iatroX's privacy policy, checked on 10 October 2026, describes query and usage processing. It should not be described as a system with no logging or external processing, and its learning context is not permission to enter patient-identifiable details into an unapproved workflow.
Define what happens when a session ends
A proposed session policy should distinguish closing the screen, signing out, locking the device and terminating connected authorisations. The appropriate behaviour may differ between a saved educational session and an action that could affect a patient's care.
For live workflows, establish what remains pending after the user leaves. A task should not become ownerless because the browser closes, nor should another user accidentally approve it without understanding its origin. Where a task legitimately continues, its ownership and status should be visible through an approved team process.
Test interruptions as well as orderly sign-out. An urgent call, a crashed browser or an unexpected room change is a more informative scenario than a demonstration in which everyone follows the ideal sequence. These tests should use synthetic material or an appropriately authorised environment.
Make recovery and exceptions part of the design
Account recovery can become a weak point if it relies on shared email addresses, informal identity checks or credentials known by several people. The local team should know how to recover access without exposing another user's history or preserving permissions that should have ended.
Emergency access also needs a defined route. The answer is not to block necessary care while administrators are unavailable. It is to agree an authorised exception process, the information it permits, how use is recorded and how it is reviewed afterwards.
Do not confuse an exception with a permanent workaround. A recurring need for emergency access may indicate that provisioning, role design or session behaviour needs improvement. The purpose of review is to improve the workflow, not merely count policy breaches.
Check the handover from the next user's perspective
A useful acceptance exercise begins after the first person has left. Ask a second authorised tester what they can see, what identity is displayed and which actions they can perform. Repeat the exercise after screen lock, browser restart and an interrupted task.
Record whether the previous user's material is inaccessible where it should be, whether current work starts in the correct context and whether pending actions retain clear ownership. Also check that the secure route is practical enough to use repeatedly during a busy clinic.
For personal learning, keep the boundary simpler: use fictional or appropriately generalised questions, an individual account and an approved device workflow. A reflective discussion about a clinical concept does not require copying an identifiable consultation into a shared AI session.
Frequently asked questions
Is a shared workstation the same as a shared AI account?
No. A shared device can support individually authenticated users, while a shared account can conceal who accessed information or performed an action.
Does closing the browser end every connected AI task?
That depends on the system's design and configuration. The deployment should explicitly test session termination, pending actions and continuing authorisations rather than assume they behave identically.
Should clinicians put patient details into a learning account for convenience?
Only an appropriately approved clinical workflow should process identifiable patient information. Fictional or genuinely generalised learning questions usually avoid the need to transfer those details at all.
Develop a clinical question without patient-identifiable detail →