Strona gabinetu medycznego Case studies

Euroklinika to centrum medyczne w Bielsku-Białej, które działa od 1999 roku w dwóch placówkach — przy ul. Żółkiewskiego 40 i ul. Piotra Skargi 9. Blisko 30 gabinetów specjalistycznych, kilkudziesięciu lekarzy, wizyty prywatne, w ramach NFZ i ubezpieczeń, własne laboratorium i punkt pobrań. Cała ta oferta opisana była na stronie zbudowanej na Drupalu 7 — systemie, który od stycznia 2025 roku nie ma już wsparcia producenta, także w zakresie poprawek bezpieczeństwa.

Największym problemem nie był jednak wygląd strony, a to, czego pacjent nie mógł na niej zrobić. Rezerwacja wizyty kończyła się na numerze telefonu do rejestracji albo na linku, który wyrzucał pacjenta do osobnego panelu e-rejestracji w nowej karcie — bez kontekstu, bez informacji o lekarzu i bez powrotu na stronę. Badania laboratoryjne wymagały wcześniejszego telefonu, żeby ustalić dzień i godzinę wizyty w punkcie pobrań.

Skutek był odczuwalny po obu stronach: pacjenci dzwonili po informacje, które mogliby znaleźć sami, a rejestracja telefoniczna była wąskim gardłem w godzinach pracy przychodni. Oferta — specjalizacje, zabiegi, cennik, lekarze — żyła w statycznych podstronach z adresami typu /poradnie-specjalistyczne/dermatologia.html, których nikt w klinice nie mógł samodzielnie rozbudować.

Euroklinika pracuje na systemie Gabos — tam są grafiki lekarzy, kontrakty, usługi i wolne terminy. Zamiast budować drugi, równoległy kalendarz na stronie (który zawsze rozjeżdża się z rzeczywistością), połączyliśmy formularz bezpośrednio z tym systemem. Pacjent widzi te same terminy, które widzi rejestracja.

Formularz prowadzi krok po kroku: specjalizacja → placówka → lekarz → cel wizyty → data → godzina → dane kontaktowe. Każde kolejne pole odblokowuje się dopiero wtedy, gdy poprzednie ma sens — dzięki temu pacjent nie może wybrać kombinacji, której klinika nie obsłuży. Cel wizyty podpowiadamy automatycznie: po wybraniu ortopedii formularz sam ustawia konsultację ortopedyczną, a nie jedno z kilkunastu badań USG.

Wybrany termin jest blokowany na czas wypełniania formularza i zwalniany, jeśli pacjent zrezygnuje — dwie osoby nie zapiszą się na tę samą godzinę. Dostępność terminów na 90 dni w przód pobieramy równolegle i trzymamy w cache’u, żeby kalendarz otwierał się od razu, a nie po kilku sekundach.

Zapisy z formularza trafiają też do panelu CMS jako log rezerwacji — rejestracja ma podglądowe potwierdzenie, kto i na kiedy się zapisał, nawet jeśli pacjent nie zadzwonił. Logi kasują się automatycznie po 7 dniach, więc dane pacjentów nie zostają w systemie dłużej, niż są potrzebne do obsługi zapisu.

Punkt pobrań ma inną logikę niż gabinet lekarski: nie wybiera się specjalisty, tylko placówkę i godzinę w wąskim oknie porannym. Dlatego laboratorium dostało własny formularz z zawężoną ścieżką — pacjent nie przechodzi przez wybór lekarza, a rezerwacje badań są rozdzielone od wizyt także w logach, więc rejestracja i laboratorium nie mieszają sobie zapisów.

Pacjent rzadko szuka „poradni” — szuka lekarza, objawu albo konkretnego badania. Rozbiliśmy więc ofertę na powiązane ze sobą typy treści: 39 specjalizacji, 43 zabiegi, 46 usług i 97 profili lekarzy. Ze strony specjalizacji wchodzi się na zabiegi, na lekarzy przyjmujących w tej poradni i na cennik — bez cofania się do menu.

Listę lekarzy da się filtrować po specjalizacji i przeszukiwać po nazwisku, a każdy profil ma własny adres, który pacjent może wysłać znajomemu albo znaleźć w Google po nazwisku lekarza.

Cennik to 269 pozycji w trzech grupach — zabiegi, usługi i szczepienia — pogrupowanych po specjalizacjach i zwiniętych w rozwijane sekcje, żeby dało się go czytać także na telefonie. Zmiana ceny albo dopisanie nowej pozycji to edycja rekordu w panelu, bez udziału programisty i bez wdrożenia. Do tego 19 pakietów badań, które klinika może składać samodzielnie.

Pacjent wpisuje „kardio”, „serce” albo „na oczy” — nie „kardiologia” i „okulistyka”. Wyszukiwarka na stronie ma własną bazę synonimów i odmian, którą rozszerza zapytanie przed przeszukaniem treści: hasło „serce” wyciąga kardiologię, „na oczy” — okulistykę. Bazę synonimów zespół kliniki może rozbudowywać w ustawieniach CMS, bez zmian w kodzie. Wyniki są pogrupowane na specjalistów, specjalizacje, zabiegi i strony, więc pacjent od razu widzi, czy trafił na lekarza, czy na opis badania.

Na każdej podstronie pacjent ma pod ręką telefon do rejestracji i przycisk umówienia wizyty, a strona kontaktu pokazuje obie placówki z osobnymi numerami, godzinami pracy i adresami e-mail — bez zgadywania, gdzie dzwonić. Formularz kontaktowy trafia mailem do kliniki i zbiera zgody RODO w jednym miejscu.

Strona placówki medycznej jest czytana także przez osoby starsze i słabowidzące. Wdrożyliśmy stały pasek ułatwień dostępu: trzy rozmiary tekstu, tryb wysokiego i niskiego kontrastu, wyłączenie skryptów i animacji, ukrycie mediów oraz reset ustawień. Wybór pacjenta zapamiętuje się między podstronami, więc nie trzeba klikać go od nowa na każdym kroku.

Stara strona miała adresy z rozszerzeniem .html i inną strukturą katalogów. Zmapowaliśmy je na nowe adresy i wdrożyliśmy 268 przekierowań 301 — z czego 210 prowadzi ze starych adresów Drupala. Przekierowania są zarządzane z panelu i działają od razu po zapisaniu, bez wdrożenia, więc klinika może reagować na kolejne znalezione stare linki samodzielnie.

Do tego doszły podstawy techniczne: wymuszony jeden adres kanoniczny (www + HTTPS), pięć map strony (strony, aktualności, specjalizacje, zabiegi, lekarze), tytuły i opisy meta ustawiane per dokument oraz obrazy serwowane w AVIF i WebP.

Nie budowaliśmy własnego systemu rezerwacji od zera. Klinika ma działający system medyczny z grafikami i kartotekami — drugi kalendarz oznaczałby podwójne wpisywanie i konflikty terminów. Zamiast tego strona pobiera i zapisuje dane w systemie, który zespół już zna.

Nie uruchamialiśmy płatności online za wizyty. Na tym etapie rozliczenie odbywa się w placówce, a dodanie bramki podniosłoby koszt i zakres wdrożenia bez wpływu na główny cel, czyli zdjęcie ruchu z rejestracji telefonicznej.

Nie wdrażaliśmy jeszcze danych strukturalnych ani rozbudowanej analityki konwersji. Pierwszym krokiem było uruchomienie i ustabilizowanie rezerwacji online oraz bezpieczne przeniesienie adresów. Znaczniki dla wyszukiwarek (placówka, lekarz, usługa) i mierzenie ścieżki rezerwacji zaplanowaliśmy jako kolejny etap — opisujemy je w sekcji „Co dalej”.

Pacjent może dziś zapisać się na wizytę i na badania laboratoryjne o dowolnej godzinie, wybierając z terminów, które faktycznie są wolne w grafiku lekarza — bez telefonu i bez przenoszenia się do osobnego systemu. Rezerwacja działa też wtedy, gdy rejestracja jest zamknięta.

Zespół kliniki prowadzi treści samodzielnie: cennik, lekarzy, specjalizacje, zabiegi, aktualności, FAQ i pliki do pobrania. Nowa podstrona ofertowa powstaje z gotowych bloków, a przekierowanie starego adresu dodaje się w panelu i działa od razu — bez zgłoszenia do wykonawcy i bez wdrożenia.

Strona wyszła z niewspieranego Drupala 7 na aktualny, rozwijany stack (Next.js 15, Payload CMS 3, PostgreSQL) i przez kolejne miesiące była dalej rozwijana — bez przebudowy fundamentu. Doszły do tego ułatwienia dostępu dla osób słabowidzących i porządek w adresach po migracji.

Liczby w tym case study opisują stan serwisu po wdrożeniu i pochodzą z produkcyjnej instancji (liczby rekordów w kolekcjach CMS, lista przekierowań, mapy strony) oraz z repozytorium projektu (zakres i tempo prac). Stan „przed” opisaliśmy na podstawie archiwalnej wersji poprzedniej strony z września 2025 roku, w tym jej systemu CMS i struktury adresów.

Prace prowadziliśmy od lipca 2025 roku, z uruchomieniem produkcyjnym na przełomie października i listopada 2025, a następnie rozwijaliśmy serwis w kolejnych miesiącach — łącznie ponad 1100 zmian w repozytorium i 29 migracji bazy danych.

Danych o ruchu i konwersjach (GA4, Google Search Console) nie zestawiamy w tym materiale — poprzednia strona nie miała porównywalnego pomiaru rezerwacji, więc porównanie „przed / po” byłoby nierzetelne. Mierzenie ścieżki rezerwacji uruchamiamy jako kolejny etap.