Roles and permissions in Dataforge PMR: controlling who can see and do what

Why is access control a clinical governance issue in a pharmacy?

Because in a pharmacy, what a person is allowed to do in the software is a legal question before it is a technical one. The Responsible Pharmacist Regulations 2008 require pharmacy procedures to identify which staff are competent to perform which tasks, the General Pharmaceutical Council (GPhC) expects services to be delivered by staff with the right skills operating within defined roles, and patient records sit under UK GDPR, where access limited to those who need it is a core security expectation, one the Data Security and Protection Toolkit now probes directly, including its recent question on authentication for clinical systems. A dispensing platform where everyone can do everything is not a convenience; it is a standing contradiction of the pharmacy's own SOPs and competence matrix.

The intricacy is real and worth naming, because pharmacy is unusual in how many legally distinct roles touch one record: six or seven levels of authority, one patient journey, often one busy room. Software either models that structure or flattens it, and flattening it means every one of those distinctions exists only on paper.

Why it matters more in an online pharmacy

Distance changes the risk profile, because in an online pharmacy the software is the premises. In a bricks-and-mortar dispensary, physical reality enforces some boundaries: the counter assistant cannot wander into the CD cabinet unnoticed, and the pharmacist can see who is doing what. Online, the equivalent boundaries exist only as permissions. Who can view a verified identity document, who can open a clinical assessment, who can alter a prescription, who can mark an order dispensed, who can export patient data: each of these is a door, and in a distance operation every door is a software setting.

The regulator's enforcement record shows why this is not theoretical. The GPhC's April 2026 review of weight management services documented failures that are, underneath, access and authority failures: supplies proceeding without the clinical check the SOP required, prescribing arrangements where the pharmacy could not evidence who reviewed what, and records that did not show whose decision a supply was. Its February 2025 distance selling guidance made superintendents jointly responsible with owners for the safety of these arrangements. When an inspector samples a patient journey and asks who approved this, who dispensed it and how you know they were entitled to, the answer is either in the permission model and the audit trail or it is nowhere. And there is a colder scenario worth planning for: when something goes wrong, a wrong supply, a data incident, an allegation against a team member, an operation with real access control can establish exactly who did what in minutes, protecting the innocent as much as identifying the failure.

Why it matters as a business

Beyond the regulatory case sits a plain commercial one: access control is how an owner protects the asset. Patient records, order history and service data are among the most valuable things a private pharmacy owns, and the most common data risks in any small business are internal and mundane: the departed employee whose login still works, the locum given full access because it was quicker, the partner who could see the whole business when they needed one dashboard. Each is an insider-risk and confidentiality exposure, and each is also a UK GDPR incident waiting for a complaint, with the reputational cost in a trust-driven market far exceeding any fine.

There is also an operational efficiency argument that gets missed: good permissions make the software simpler for each person, not more restricted. A dispenser whose screen shows dispensing, a prescriber whose dashboard shows cases awaiting review and a counter colleague who sees the diary all work faster than staff navigating an everything-interface, and they make fewer errors, because the system only offers them actions that are theirs to take. Least privilege, done properly, feels like focus rather than restriction.

How roles and access control work in Dataforge PMR

Dataforge PMR is built around per-user roles and access control: every team member has their own account, what they can see and do is governed by their role, and staff are assigned per location, so access follows where someone actually works. A multi-site operation runs this from one dashboard, with each pharmacy, clinic or virtual room carrying its own staff list, which means a pharmacist at branch one, a locum covering branch two on Saturdays and a partner prescriber reviewing cases remotely each hold access shaped to their actual involvement rather than a share of everything.

The companion to the permission model is attribution: every action in Dataforge PMR is logged against the named user who took it, from booking changes through clinical decisions to prescription generation, label printing, dispensing states and despatch. That pairing is the whole governance mechanism in two parts: permissions decide who can act, and the audit trail records who did, which together answer the inspector's question, the incident investigator's question and the owner's question with the same evidence.

Mapping your team to the model

The practical setup method is to configure access from your competence matrix, the document our SOP guide builds, which already records who is signed off for what. The mapping is then mechanical rather than political: each person's access reflects the tasks they are signed off to perform, at the locations they work, and nothing beyond it. The superintendent and owner hold the wide view. Pharmacists and prescribers hold the clinical layers. Dispensers hold the dispensing workflow within their sign-off. Front-of-house holds bookings and patient contact. Delivery-facing staff hold despatch. Where the matrix says not yet, the access says not yet, and when a sign-off lands, the access follows it, which turns permissions into a live reflection of competence rather than a launch-day snapshot that decays.

A quarterly access review, twenty minutes against the staff list, catches the drift that daily operations create, and it belongs in the same quarterly rhythm as the compliance calendar's other sweeps.

What this looks like at inspection

Pulled together, the access model turns a difficult inspection conversation into a short one. Asked how the pharmacy controls who can perform clinical and dispensing tasks, the answer is the role model mapped to the competence matrix. Asked who approved, assembled, checked and despatched a sampled supply, the answer is four named entries on one audit trail. Asked how patient data access is limited, the answer is per-user, per-location access and no shared logins. Asked what happens when someone leaves, the answer is the leaver step with the record intact. None of these answers requires preparation, because each is a property of how the system runs rather than a document written for the visit, which is the standard this whole wiki keeps returning to: evidence as a by-product of work.

Key takeaways

FAQs