Running two clinic locations without running two systems
2026-10-02 · MedSlay
A second location is usually a sign that the first one is working. It is also the point at which a practice discovers whether its systems were built for a clinic or for a doctor — because a doctor is one person, and now they are in two places.
Most of what goes wrong is not dramatic. It is a slow doubling: two appointment books, two sets of patient files, two WhatsApp groups for staff, two spreadsheets at month end. Each one is reasonable on its own. Together they turn one practice into two half-practices sharing a name.
Where the second clinic goes wrong
The failures cluster around four things, each with a specific fix.
what happens when that changes for a week.
first clinic; their file is there; today they are here.
A manager who covers both should see both. Neither should have to log into two systems to do it.
location, without anyone adding columns together on a Sunday.
- The roster. Which doctor is where, on which days, at what hours — and
- The patient who turns up at the other location. They were seen at the
- Staff access. A receptionist who works at one site should see that site.
- Numbers by site. Revenue, visits, no-shows and outstanding bills, per
One doctor, two rosters
A single timetable looks fine until the doctor is at location B on a Tuesday the system thinks they are at A.
What you want is one doctor with timings per location — Monday and Wednesday mornings here, Tuesday and Thursday evenings there — and bookings that are only ever offered against the location the doctor will actually be at. A patient should not be able to book a slot at the wrong site, and the front desk should not be the thing preventing it.
The same applies to visiting consultants. A specialist who comes to your second location one afternoon a week needs to exist in the system once, with that one afternoon attached to that one place, not as a second user with a second password.
The patient who turns up at the other location
This is the one patients notice. Someone registered at your first clinic walks into the second with the same complaint they had last month and is asked for their name, age, allergies and history as though they had never been seen.
The fix is a boring one: the patient record belongs to the patient and the doctor, not to the building. Where they were first registered is a fact about them, not a wall around their file. The notes, the prescriptions and the reports from the first visit should be in front of the doctor at the second, with nothing re-entered and nothing carried in a plastic bag.
A record that moves between locations is still one record under one practice. A record shared with a different doctor is a different question, and should be a deliberate act with the patient's agreement rather than a side effect of being in the same software. More in what DPDP means for a clinic.
Staff at one site, and staff at both
Access is where a single shared login quietly becomes the system. One password on a sticky note, used by whoever is on the desk, at either site.
What a practice actually needs is roles that follow people, not buildings. A receptionist assigned to one clinic sees that clinic's queue, bookings and patients. An assistant who supports one doctor sees that doctor's patients wherever the doctor is. A manager covering both sites sees both. And when someone leaves, their access ends in one place — not in two systems, one of which everyone forgot about.
Numbers by site, not by spreadsheet
Month end is where a two-system practice pays for itself. Visits, revenue, pending payments and no-shows have to be pulled from two places and reconciled by hand, usually by the person with the least time to do it.
One system should answer the questions directly: which location is busier on which days, which has the higher no-show rate, where the outstanding bills are. Not because the numbers are complicated, but because questions that take an hour to answer stop being asked. The OPD waiting-time piece has the three numbers worth tracking; at two locations, track them per site.
Before the second location opens
- Add the location, not a new account. The practice is one practice. A second login, a second subscription or a second database is the first step toward two half-practices.
- Set each doctor's timings per location, including visiting consultants, so bookings can only land where the doctor will be.
- Decide who sees what, by role and by site, and write it down. Then set it up that way rather than sharing one login until there is time.
- Confirm a patient from site A can be seen at site B with their full history visible and nothing re-entered. Test it with a real file before opening day.
- Check the month-end view shows each location separately and the practice as a whole, from the same screen.
Where MedSlay fits
MedSlay treats a practice as one thing with several places in it. A doctor has a home clinic and can visit others, with timings set per location; the public directory shows those timings grouped by clinic, and a booking is only ever offered against a clinic the doctor actually visits. Patient records live against the patient and the doctor, so a file opened at one location is the same file at the next. Assistants are assigned to doctors, and access is by role rather than by shared password.
It does not decide how a second location should be run; those are practice decisions. What it changes is whether they can be run on one system — see how it handles a multi-location practice.