A multi-location clinic: when a website is enough, and when you need a patient portal

"We have three sites now, it is probably time for a patient portal." I hear this more and more often from operations directors of clinic networks. My usual reply is a question: what would the patient actually do in that portal? The list is long: book, check opening hours, see results, download an e-prescription, pay, message a doctor. When we go through it item by item, it usually turns out that half of it is handled by a good website with no login at all, a sizeable part is already handled by the state through the Internet Patient Account, and only what is left is the real question about a portal.

This piece is about taking that list apart for your own network. I am writing it honestly in both directions: some clinic networks will genuinely benefit from a portal, and for others it would be an expensive, demanding system that patients log into twice a year. The difference rarely lies in the number of locations. More often it lies in how patients live with you between visits.

A note for readers outside Poland: the regulatory examples here are Polish, because that is where we work. The decision framework travels well, and most EU countries have some state-run equivalent of the patient account described below.

I will start with what often gets skipped because it seems obvious. In a network of several clinics, most patient frustration comes from not knowing which location to go to, who sees patients there and how to book. None of that requires an account.

A separate page for each location. Its own address, opening hours, phone number, directions and parking, the doctors who see patients at that particular site, and the services available there. If one site has ultrasound and another does not, the patient should see that before they set off. One shared "Contact" page with three addresses stacked on top of each other is not enough.

A Google Business Profile for each site. A patient searches for "clinic [neighbourhood]" and sees a map. Every location needs its own profile, and the name, address and phone number in the profile should match its page on your website exactly. Opening hours that differ between Google and the website are one of the more common reasons for annoyed phone calls.

Structured data for each location. Schema.org has a MedicalClinic type that describes a clinic: address, hours, phone, coordinates. A separate description for each location helps search engines understand that this is one network with several places, not one clinic with three phone numbers.

Online booking with a choice of location. The patient picks the site, the specialist and the slot, and the appointment lands in that site's calendar. Or the other way round: they pick a doctor and see where that doctor works this week. This is the most important part of the whole website, and it is worth keeping it in your own hands. I explained why when comparing booking portals with your own system.

Text message reminders with a cancel option. A day or two before the visit, with the address of the right site and a link that lets the patient cancel without calling. In a multi-location network, the address in the text matters more than you would think: a patient who goes to the wrong site loses the appointment, and you lose the slot.

Google reviews for the right site. The request for a review after a visit should lead to the profile of the location the patient actually visited. Otherwise every review goes to the main site, and a new branch looks empty for a year.

All of this works without a login and without storing medical records on the website. Booking itself is health data, because which specialist someone books with says a lot about them. I covered that in the piece on what the GDPR requires from a clinic website. But it is still a much smaller scope than a portal with results and treatment history.

In Poland, every patient has access to the Internetowe Konto Pacjenta, or IKP, the Internet Patient Account. It is a free, state-run patient record operated by the Minister of Health, available on pacjent.gov.pl and in the mojeIKP mobile app. Patients log in with the government's trusted profile, an electronic ID card, the mObywatel government app or their online banking.

What do they find there? E-prescriptions (issued, filled and partially filled), e-referrals, electronic sick notes, visit history, vaccination history and electronic medical records, for example laboratory results with descriptions, diagnostic test reports and hospital discharge summaries. They can also authorise a family member to collect prescriptions or view their records.

This bears directly on your decision. Since 1 July 2021, every healthcare provider in Poland, including private ones without a contract with the NFZ (the National Health Fund, the public payer), has had to report medical events to P1, the national e-health platform run by Centrum e-Zdrowia, the government's e-health centre. Electronic medical records, known in Poland as EDM, travel with those events. Pacjent.gov.pl puts it plainly: if a patient cannot see these documents in IKP, it means the provider has not shared them, even though it is legally required to.

The conclusion is simple. Building e-prescriptions and e-referrals into your own portal duplicates a state system that patients will use anyway, because it collects documents from every provider they have seen, not just yours. Your job is rather to make sure your practice management system (in Poland usually called the system gabinetowy, the software that holds the calendar and the medical records) sends documents to P1 reliably. On the website, a short, well written page called something like "Where to find your e-prescription and results", explaining how to set up IKP and what you will see there, is enough. It answers a good share of the "is my prescription ready yet" calls, and it costs a few paragraphs of text.

A portal makes sense when patients need something from you that neither the website nor IKP provides, and they need it regularly. Below are the signals we see most often. There is no numeric threshold that settles it. The more of these fit your network, the more seriously a portal is worth considering.

And the opposite signals, just as important:

If the second list describes you better, a portal is not your problem right now. The website, booking and information about IKP are.

Before you commission a portal, check what the vendor of your practice management system already offers. Many vendors of systems popular in Poland have their own patient portal or online booking module, where patients book visits and check test results online. It is often a paid add-on that someone at the clinic has already seen in the price list and put off for later.

"Let's use what our system vendor provides" is a perfectly valid answer, and for many networks the best one. The data does not leave the system where it already lives, the integration is ready, and security is the responsibility of the company that knows its own database best. I say this even though we build portals ourselves: if the vendor's portal does what you need, there is no reason to pay twice for the same thing.

When assessing such a portal, ask the vendor a few concrete questions:

A common setup that works well is a split: the website, booking, reminders and reviews are yours and fitted to your network, and behind a "My account" button sits the vendor's patient portal. The patient gets one starting point, and you do not maintain a second copy of the medical records.

Your own portal only makes sense when the vendor's portal does not support what your network earns from or what sets it apart: subscriptions on your own terms, care programmes, document flows between locations that the system was never designed for.

I am not writing about money here, but about the commitments that come with a portal and stay for years. They decide whether a portal pays off, and they are the least visible part of any proposal.

Logging in to health data. Article 32 of the GDPR does not name a specific method, it requires measures appropriate to the risk. For medical records, in practice that means a second login factor, sensible session expiry and well thought out account recovery. The weakest point is often not the password but the reset: if giving a phone number that someone changed at the front desk over the phone is enough, every other safeguard is irrelevant. Then there is the question of how you verify identity when an account is created, and what happens to a child's account when the child comes of age.

Legal basis and impact assessment. Health data is special category data under Article 9 of the GDPR. Article 35(3)(b) lists large-scale processing of such data among the cases where a data protection impact assessment, or DPIA, is required. UODO, the Polish data protection authority, has also published a list of processing operations that require one. A network of several clinics with a portal for all its patients usually falls within that. We are not a law firm, and the final assessment belongs to your data protection officer, but the DPIA is worth planning before the project, not after launch.

Access logging. Who opened a patient's document, when, from which account, from where. A patient may ask who has seen their records, and after an incident these logs are the first thing anyone asks for. The logs themselves must be protected and have a defined retention period.

NIS2, if it covers you. Poland's amended National Cybersecurity System Act (known as KSC), which transposes NIS2, has applied since 3 April 2026. Medium and large healthcare providers can be important or essential entities. For entities that met the criteria when the act came into force, the deadline to register in the national list passed on 3 October 2026, and security measures have to be in place by 3 April 2027. An internet-facing portal then becomes part of a system subject to risk management and incident reporting. I wrote more about whether NIS2 applies to you in the piece on NIS2 in 2026.

Integration with the practice management system. The hardest and most fragile part. The portal reads appointments, results and documents from the system, and sometimes writes to it. Any update on the vendor's side can break that integration, so it has to be clear who will notice, who will fix it and how fast.

Maintenance and support. Security updates, testing, monitoring. And the most often forgotten item: someone has to take the "I can't log in" calls. In practice they go to the same front desk the portal was supposed to relieve.

Accessibility. The portal is used by older people, people with low vision, people with hand tremors. Login forms, one-time codes and PDF documents are where accessibility breaks most often. The portal should meet WCAG 2.2 AA just like the website.

None of this is a reason not to have a portal. It is a reason to cost it honestly and compare it with the vendor's portal. I wrote separately about what a clinic website itself really costs.

In practice, clinic networks take one of three paths.

Notice that the starting point is always the same. A website with proper location pages, booking and reminders is needed in each of these options, and a portal is built on top of it, not instead of it. That is why I recommend starting with the website, even if a portal is planned for next year.

If you run a network of several clinics, check the basics first: does every location have its own page and its own Google profile, can a patient book online at a specific site, do they get a text with the right address, and does the review request go to the right profile. Online booking, text reminders and Google reviews are described on our page for healthcare providers. GDPR, WCAG and NIS2 requirements are built in from day one, in the background, so the patient simply sees a convenient website. Booking, reminders and reviews for clinics are on medova.health.

If you are facing a decision about a portal, write to me. We will go through the list in this piece together and check what the website covers, what IKP covers and what your vendor's portal covers. I lead the conversation about scope myself, and if it comes to a project, design and implementation are done by the team the clinic works with directly. If it turns out the vendor's portal is enough, that is exactly what we will say.