Managing multiple pharmacy locations from one Dataforge PMR account

How does Dataforge PMR handle multiple locations?

Every site in Dataforge PMR is a location with its own services, its own staff and its own calendar, and the whole estate is managed from one account and one dashboard. A location can be a physical pharmacy, a clinic or a virtual consultation room, so a typical growing operation, one dispensing branch, one aesthetics clinic and a video consultation service, runs as three locations under one roof. Services are defined once and assigned to the locations where they run, availability is set per service per location, staff are assigned to the locations where they work, and the Bookings calendar presents everything in one view, so the owner sees the whole diary while each site sees its own.

The design principle is separation with oversight: each location operates as itself, while the account level holds the things that should be common. That split is not just tidy software design; it mirrors how UK pharmacy regulation actually works, which is the next section's point.

The governance reality: one business, many registered premises

The regulatory structure of a pharmacy group is the opposite of its commercial structure, and multi-location software has to serve both at once. Commercially, a group is one business with one owner and one brand. In regulation, each pharmacy premises is registered individually with the General Pharmaceutical Council (GPhC), each is inspected individually and each must meet the standards for registered pharmacies on its own evidence, while the superintendent pharmacist carries accountability across the whole company, jointly with the owner for distance services under the February 2025 guidance.

Branch three's records, procedures and staff competence are what is being examined, and that is exactly the failure mode the GPhC's April 2026 review documented in the wider market: risk assessments that existed somewhere but not here, staff not following the procedures the organisation nominally had, and records that could not evidence decisions at the site where they were made. For a multi-location operator, the platform's job is therefore double: give each location a complete, self-standing evidence trail, and give the superintendent a live view across all of them, because accountability without visibility is how superintendents end up answering for failures they had no way to see. One dashboard across every location, with every action logged against a named user at a known site, is that visibility.

Services and availability across sites

The service catalogue is the natural place to enforce group consistency, and Dataforge PMR's model encourages it: define the service once, with its duration, price and category, then assign it to the locations where it genuinely runs. A travel clinic offered at two branches and a weight management service delivered from the virtual room are the same services everywhere they appear, which means the patient experience, the assessment attached and the record generated are identical regardless of entry point. What varies by location is availability, and it should: each site's calendar reflects its actual rooms, staff and hours, and a service launched at a new branch needs its availability configured there deliberately rather than inherited, as the Bookings configuration guide covers.

Two operational rules keep this clean as a group grows. First, resist per-branch service drift: if branch two wants to run the consultation differently, that is a service design conversation for the group, not a local variation, because variations are precisely what turn one inspection finding into a group-wide one. Second, launch new locations narrow: one or two services configured completely and tested end to end at the new site before the full catalogue is switched on, the same discipline the getting started guide applies to a first branch.

Staff, roles and locations

Access follows work: staff are assigned to the locations where they operate, with their role governing what they can see and do there, so a pharmacist at one branch, a locum covering weekend shifts at another and a manager overseeing three sites each hold precisely the access their job describes. The full reasoning lives in the roles and permissions guide, but the multi-location layer adds its own specifics: new locations start with their own staff list rather than a copy of everyone, and the group-level roles, owner, superintendent, are the deliberate exceptions whose wide view exists precisely because their accountability is wide.

Attribution completes the model. Every action in Dataforge PMR is logged against the named user, and in a multi-location operation that log answers the question single-site pharmacies never have to ask: not just who did this, but where. When a supply from branch three is questioned months later, the trail shows which site, which team member and which decision, which protects every other branch and every other person from an investigation that would otherwise have to look at all of them.

Patients across locations

Patient records belong to the patient, not the branch, which is the quiet advantage of running a group on one platform. A patient who books a consultation at one branch, attends the virtual room for follow-up and collects from another site is one record with one history: the assessment, the notes, the documents, the prescriptions and every supply, in sequence, wherever each event happened. That is better clinical care, the second clinician sees the whole picture, and it is better governance, because duplicate detection works properly across the estate: the matching on name, date of birth and email described in the order screening guide runs against the group's order history, so a patient attempting to obtain the same treatment from two of your branches surfaces as a flag rather than succeeding through the gap between systems.

The alternative, separate systems or separate accounts per site, recreates exactly the fragmentation that lets things slip through: histories split by branch, duplicates invisible across sites and a patient journey nobody can produce whole. If the group is one clinical operation, its records should be too.

The owner's view: running the group from one dashboard

Day to day, multi-location management in Dataforge PMR is the difference between checking on your business and touring it. The dashboard shows the whole estate: every location's bookings on one calendar, orders moving through review and dispensing across sites, and the audit trail accumulating underneath. For an owner, the practical rhythms this enables are simple. The morning view: today's diary across all locations in one look. The weekly view: which services are filling where, which branch's availability is over or under-provisioned, where the review queue is building. And the governance view, which is the superintendent's: sampling patient journeys from any site without visiting it, exactly the exercise an inspector performs, run internally before the regulator runs it externally.

The platform scales from one branch to twenty on the same model, which matters most at the moment of growth: adding a location is an afternoon of configuration rather than a new system, and the new site inherits the group's governance from day one rather than developing its own habits and merging later.

Key takeaways

FAQs