Giving a virtual assistant access to patient records: what to insist on

You give a remote admin assistant access to patient records the same way you would give it to a receptionist sitting in your building: their own named login inside your existing system, set to the lowest permission level the job needs, with a data processing agreement signed before the first day. Nothing gets exported, nothing gets copied out, and no password gets shared.

That is the whole answer. The rest of this is the detail, because the detail is where clinic owners get uncomfortable, and they are right to be.

The short version

• Give a named login inside your own system, never a shared one.
• Set permissions to the lowest level that still lets the work happen.
• Sign a data processing agreement before the first login is created.
• Patient data stays in your software. Nothing is exported or emailed out.
• You remain responsible for the record. That part does not transfer.

Who is responsible for the data, and who is not

When you bring in outside admin help, the clinic stays what the ICO calls the controller, and the person doing the admin is a processor. In plain terms, you decide what happens to the data and they act on your instructions. The ICO sets out the difference between the two roles, and it is worth ten minutes of your time before you hire anybody.

This matters more than it sounds. Handing over the work does not hand over the responsibility. Your regulator still treats the record as yours: the General Osteopathic Council's practice standards say patient records must be comprehensive, accurate, legible and completed promptly, and that expectation sits with the osteopath, not with whoever types them up.

I am not a data protection officer and none of this is legal advice. If you want certainty about your own setup, the ICO's guidance is the place to start, and your indemnity provider will usually have a view worth asking for.

A named login, not a shared one

The most common shortcut I see is a clinic owner handing over their own login details. It is quick, it works, and it removes every useful thing about the audit trail. Once two people are inside one account, nobody can say who booked, who cancelled, who amended an invoice or who opened a treatment note.

A named login fixes that at no cost. Every practice system I have worked in stamps actions against a user, so when a question comes up six months later there is an answer instead of a guess.

It also makes leaving clean. When the arrangement ends you switch off one account, rather than changing a password you have used for four years and typed into eleven other places.

Permissions: the lowest level that lets the job get done

Most practice software has this built in already, and most clinics never touch it. Cliniko, the system I know best, has six user roles. A scheduler can book, move and cancel appointments and see basic patient details, while never seeing your financials or treatment notes. A receptionist adds invoicing and payments, and access to letters and file attachments can be switched on or off separately on top of that.

The useful question is not whether you trust the person. It is what the job actually needs. Someone chasing insurer shortfalls needs invoices, payments and remittances, and almost never needs clinical notes. Someone running your diary needs the calendar and patient contact details and very little else. Cliniko publishes a guide for practice owners on setting an outside person up on the system, which tells you how ordinary this arrangement has become.

The same shape exists in PPS, TM3, WriteUpp and Semble under different names. If you want the detail of what this looks like day to day in one system, that is on the Cliniko page.

The agreement that should exist before the first login

A data processing agreement is the written record of what the other person is allowed to do with your patients' data. The ICO lists the terms a processor contract has to contain, and the list is shorter and less frightening than people expect: processing only on your documented instructions, a duty of confidence, appropriate security measures, rules about sub-processors, help with patients' data rights, help with your own obligations, end-of-contract provisions, and audits.

The contract also has to describe the processing itself, which the ICO breaks down as the subject matter and duration, the nature and purpose, the type of data and the categories of people it relates to, and your rights and obligations. That is the part that forces a useful conversation, because it makes both sides write down exactly which jobs are in scope and which are not.

Anyone doing this work properly will have one ready and will not need chasing for it. If you ask for a data processing agreement and get a vague answer, you have learned something.

The things that should never happen

Patient data leaving your practice software is the one to watch. A spreadsheet of names and numbers pulled out for a recall push, a list of outstanding balances forwarded to a personal email account, appointment details sorted out over WhatsApp. All of it is convenient, all of it puts patient data somewhere you no longer control, and none of it needs to happen. The work can be done inside the system.

The rest is simpler. No shared passwords. No access left switched on after the work has stopped. No administrator login with full export rights for a job that never involves exporting anything. And no arrangement where you could not tell me today which accounts can open your treatment notes.

If something does go wrong, the clinic is the one that reports it. The ICO explains what counts as a personal data breach and when it has to be reported. Read it once now rather than at the point you need it.

What to ask before you hand anything over

Five questions, and you can get through all of them in a first conversation.

• Will you work inside my system on a named login, or do you want data sent to you?
• Which permission level do you actually need for the jobs we have agreed?
• Do you have a data processing agreement ready to sign, and can I read it first?
• Where does anything you download or type sit, and for how long?
• What happens to your access on the day we stop working together?

The answers matter less than the hesitation. Someone who does this regularly will get through all five without pausing, because they have had the conversation before. Someone improvising is telling you they have not thought about it, and patient data is a poor place to find that out later.

None of this is hard. It is one login, one permission level and one signed document, set up once at the start. Where clinics get uneasy about remote admin, it is usually because none of those three things were ever put in place, and that is a fixable problem rather than a reason to keep doing the admin yourself at nine at night.