Rozwiązania · Kliniki stomatologiczne
Strona kliniki stomatologicznej jest oceniana według jednej rzeczy: czy osoba znajduje usługę, której potrzebuje, z ceną i jednostką — za ząb, za szczękę, za sesję — oraz czy wie, czy wchodzi to w ubezpieczenie, czy nie. Reszta to dekoracja. Budujemy strukturę, która to utrzymuje, i panel, z którego personel zmienia to samodzielnie.
Już zbudowanePracę można sprawdzić z zewnątrz już teraz: publiczne dane rejonowego centrum stomatologicznego, które administrujemy, są serwowane jako plik strukturalny — 89 usług, każda z kategorią, podkategorią, nazwą, ceną, jednostką miary i wskaźnikiem kwalifikacji do obowiązkowego ubezpieczenia, z czego 27 oznaczonych jako kwalifikujące się; 7 kategorii i 10 podkategorii, sprawdzonych przez nas 06.09.2026. Druga część dowodu to zabezpieczenie, z diffem w historii: przy przejęciu hasło administratora było porównywane w przeglądarce i trafiało do publicznego pakietu JavaScript, a zapisy przez interfejs programistyczny mogła wykonywać każda osoba z internetu. Doprecyzowanie, żeby nie przypisać nam więcej, niż jest nasze: pierwsza wersja strony nie jest nasza. Wkład, który da się pokazać z diffem, to przejęcie, zabezpieczenie, typy, ciągła integracja i higiena zależności.
Klinika stomatologiczna nie sprzedaje „usług”. Sprzedaje bardzo długą listę pozycji taryfowych z jednostkami, które nie przypominają niczego z innej branży: za ząb, za szczękę, za ekstrakcję, za leczony przypadek, za sesję, za wizytę, za zabieg. Osoba szukająca w internecie nie szuka kliniki, tylko swojej pozycji: ile kosztuje ekstrakcja, czy płaci się za ząb czy za wizytę, czy jest objęta ubezpieczeniem. Strona, która odpowiada na to, jest użyteczna; strona z zakładką „Cennik” i załączonym PDF-em nie jest.
Drugą rzeczą, której wymaga rzeczywistość kliniki, jest możliwość zmiany listy bez programisty. Cenniki się zmieniają, lekarze się zmieniają, dyżury są ogłaszane inaczej zimą. Jeśli każda zmiana przechodzi przez dewelopera, lista zostaje stara i po kilku miesiącach pacjenci przychodzą z ceną z zeszłego roku. Struktura, którą budujemy, trzyma dane publiczne — usługi i zespół — w uporządkowanych plikach czytanych zarówno przez interfejs programowania, jak i bezpośrednio przez widoczną część strony, a personel edytuje je z panelu.
Trzecia rzecz, której nikt nie wpisuje w brief, a która ma największe znaczenie, to kto może pisać do tej listy. Przy przejęciu projektu, o którym tutaj piszemy, dowolna osoba z internetu mogła wysłać zapis do interfejsu programowania, a hasło panelu trafiało do pakietu JavaScript serwowanego przeglądarce — ponieważ jego weryfikacja odbywała się w przeglądarce. Przenieśliśmy weryfikację na serwer: hasło nie opuszcza już serwera, zwracany jest podpisany token ważny dwanaście godzin, z limitem ośmiu prób na piętnaście minut na adres IP i porównaniami w czasie stałym; interfejs nasłuchuje tylko na adresie lokalnym, więc serwer WWW jest jedyną publiczną drogą.
Oznaczenie objęcia obowiązkowym ubezpieczeniem zasługuje na osobne zdanie, bo to pole o największej wartości dla pacjenta i największym ryzyku dla kliniki: to stwierdzenie z konsekwencjami. Dlatego żyje jako dane edytowane przez instytucję, a nie jako tekst przez nas napisany na stronie; my budujemy pole, wyświetlanie i możliwość poprawienia go w minutę.
Co obejmuje
Struktura danych każdej usługi ma kategorię, podkategorię, nazwę, cenę, jednostkę miary i wskaźnik kwalifikowalności do obowiązkowego ubezpieczenia. Jednostki są rzeczywistymi jednostkami tej branży — ząb, szczęka, ekstrakcja, leczony przypadek, sesja, wizyta, konsultacja, znieczulenie, procedura, badanie, interwencja — ponieważ cena bez jednostki wywołuje dokładnie tę rozmowę, której recepcja chce uniknąć.
Kategoria i podkategoria, a nie płaska lista. W pracy, o której piszemy: 7 kategorii i 10 podkategorii ponad 89 usług. Skala ma znaczenie — przy mniej niż stu pozycjach taksonomia na dwóch poziomach wystarcza; powyżej kilkuset struktura staje się inną rozmową i mówimy to z góry, a nie po fakcie.
Wskaźnik kwalifikowalności znajduje się przy każdej usłudze, w danych publicznych, i może być edytowany przez klinikę. W przywołanej pracy 27 z 89 usług jest oznaczonych jako kwalifikowalne. Nie wpisujemy sami, co wchodzi do ubezpieczenia, i tego nie wyprowadzamy: to stwierdzenie instytucji, z konsekwencjami dla pacjentki lub pacjenta, i musi ona móc je skorygować w dowolnym momencie.
Nie jedna strona „Usługi”. Serwis ma 22 ekrany, od usług i cen po nagłe przypadki, ortodoncję, implanty, pedodoncję, przejrzystość i opinię zwrotną. Powód jest praktyczny: osoba szukająca „nagły przypadek stomatologiczny” w niedzielny wieczór nie chce strony ogólnej, a strona sekcji ma co powiedzieć o godzinach i o tym, co się w niej robi.
Usługi i zespół są edytowane z panelu, a zapisy wymagają ważnego tokena; odczyty pozostają publiczne, aby strona działała bez uwierzytelniania. Skutek dla kliniki: zmiana taryfy wchodzi tego samego dnia, a nie w następnej iteracji rozwojowej.
Uwierzytelnianie odbywa się na serwerze i zwraca token podpisany HMAC-SHA256, ważny 12 godzin, z maksymalnie 8 próbami na 15 minut na adres IP i porównaniami w stałym czasie. Sekret podpisywania jest generowany samodzielnie, w pliku o ograniczonych uprawnieniach, przechowywanym poza repozytorium. To są liczby z kodu, a nie ogólne zasady — można je odczytać i zakwestionować.
Nasłuchuje tylko na adresie lokalnym, więc serwer WWW z przodu jest jedyną publiczną drogą; lista dozwolonych domen jest jawna, a treść żądań jest ograniczona do 1 MB. Zapis wymaga tokena, odczyt nie. To typowa konfiguracja — problem polega na tym, że gdy jej brakuje, nie widać tego z zewnątrz aż do dnia, kiedy ktoś to znajdzie.
Sprawdzenie, które kompiluje i weryfikuje typy, robi też coś, co robi niewiele projektów: szuka sekretów w zbudowanym pakiecie i kończy się niepowodzeniem, jeśli je znajdzie. Jest to bezpośrednio związane z naprawioną wadą przy przejęciu — hasło trafiło do publicznego pakietu właśnie dlatego, że nic tego nie sprawdzało. Do tego dochodzą tygodniowe aktualizacje zależności.
Nie potwierdza samodzielnie wizyty: zbiera zgłoszenie, a potwierdzenie wymaga albo osoby, albo połączenia z systemem rejestracji kliniki — to osobna praca, z własnymi warunkami. Nie publikuje medycznych informacji napisanych przez nas: treść o leczeniu należy do specjalistek i specjalistów. I nie decyduje, co wchodzi do ubezpieczenia.
Traseul
Pierwsza dostawa to lista pozycji taryfowych z jednostką każdej z nich i oznaczeniem pokrycia, w formie, w jakiej prowadzi ją klinika. Jeśli lista nie istnieje w ustrukturyzowanej formie — a zwykle istnieje jako plik arkusza kalkulacyjnego albo jako dokument — strukturujemy ją my, a klinika ją potwierdza. Projekt przychodzi później, bo zależy od tego, ile jest pozycji.
Ekrany publiczne i panel, z którego się edytuje, nie są robione osobno, bo inaczej pojawiają się wyświetlane pola, których nie da się edytować. Dostarczamy stronę z wczytanymi rzeczywistymi danymi, a nie z treścią zastępczą — strona kliniki wypełniona prowizorycznym tekstem nie może być oceniona przez nikogo.
Uwierzytelnianie na serwerze, podpisany token, limit prób, interfejs rejestracji tylko pod adresem lokalnym, lista dozwolonych domen, limit rozmiaru ciała żądań. Dostarczamy wynik sprawdzenia wykonanego z zewnątrz: co można odczytać bez uwierzytelniania, a czego nie można zapisać.
Przekazujemy dostępy, dokument uruchomienia i krótki instruktaż dla osoby, która będzie zmieniać ceny i zespół. Dostawy nie uznaje się za zakończoną, dopóki ktoś z kliniki nie wykona samodzielnie zmiany, która pojawi się na stronie.
Dane
Zasady różnią się w zależności od branży. To są te, które stosują się w klinikach stomatologicznych.
Przykład
Sytuacja
Przy przejęciu strony centrum stomatologicznego panel administracyjny miał dwa problemy, które były widoczne tylko od wewnątrz. Pierwszy: hasło było porównywane w przeglądarce, więc trafiało do publicznego pakietu JavaScript. Drugi: żądania zapisu do interfejsu programowania mogła wysyłać dowolna osoba z internetu, a port był wystawiony bezpośrednio.
Co zbudowaliśmy
Przenieśliśmy weryfikację na serwer: uwierzytelnienie zwraca token podpisany HMAC-SHA256, ważny 12 godzin, z limitem 8 prób na 15 minut na adres IP i porównaniami w czasie stałym; sekret podpisywania generuje się samodzielnie, z ograniczonymi uprawnieniami, poza repozytorium. Interfejs programowania pozostał nasłuchujący tylko na adresie lokalnym, z serwerem webowym z przodu, listą dozwolonych domen i limitem treści żądania do 1 MB. Zapisy do usług i zespołu wymagają tokena; odczyty pozostały publiczne. Ponad tym wszystkim, ciągła integracja, która kompiluje, sprawdza typy i odrzuca pakiet, jeśli znajdzie w nim sekret.
Co z tego wyszło
Publiczne dane kliniki można dziś sprawdzić z zewnątrz: 89 usług, każda z kategorią, podkategorią, ceną, jednostką i wskaźnikiem pokrycia przez ubezpieczenie, z czego 27 oznaczonych jako kwalifikujące się. Zmieniło się to, kto może w nich zapisywać.
Czego nie mówi ten przypadek
To nie my zbudowaliśmy pierwszą wersję strony. Z historii repozytorium część commitów należy do zewnętrznych deweloperów. Wkład, który możemy pokazać diffem, to przejęcie: bezpieczeństwo, ciągła integracja, typy, zależności.
Pytania
Tak — to połowa pracy. Usługi i zespół są edytowane z poziomu panelu; zapisy wymagają uwierzytelnienia, odczyty pozostają publiczne. Nasza rekomendacja: przy przekazaniu osoba, która będzie się tym zajmować, dokonuje zmiany na naszych oczach, żebyśmy wiedzieli, że działa z jej ręki, a nie z naszej.
Jako wskaźnik przy każdej usłudze, w tych samych danych, które edytujecie. W pracy, którą cytujemy, 27 z 89 usług jest oznaczonych jako kwalifikujące się. My budujemy pole i wyświetlanie; to, co dokładnie jest kwalifikujące się, jest stwierdzeniem instytucji, bo ma skutki dla pacjentki lub pacjenta i dla kliniki.
Bo w stomatologii cena nie jest za wizytę. Jest za ząb, za szczękę, za ekstrakcję, za leczony przypadek, za sesję. Cena wyświetlona bez jednostki wywołuje dokładnie taką rozmowę, jaką recepcja prowadzi dziesięć razy dziennie, a co gorsza, wrażenie pacjentki lub pacjenta, że powiedziano coś innego przez telefon.
Może zbierać zgłoszenie. Potwierdzenie terminu wymaga albo osoby, która sprawdza grafik, albo połączenia z systemem zapisów kliniki — to osobna praca, z wcześniejszym sprawdzeniem kompatybilności. Nie nazywamy „zapisem online” formularza, który wysyła e-mail.
Specialistki kliniki. Nie piszemy informacji klinicznej i nie „optymalizujemy” jej pod wyszukiwanie, ponieważ oznaczałoby to formułowanie twierdzeń medycznych w imieniu instytucji medycznej. Porządkujemy tekst, stawiamy pytania, na które tekst ma odpowiedzieć, i publikujemy go po potwierdzeniu.
Tak, i właśnie o tym jest praca, o której piszemy tutaj. Co robimy najpierw przy przejęciu: sprawdzamy, co da się opisać z zewnątrz, gdzie są hasła i co trafia do pakietu serwowanego przeglądarce. W cytowanym przypadku hasło administracyjne trafiało do publicznego pakietu, a zapisy mogły być wykonywane przez dowolną osobę. Przenieśliśmy weryfikację na serwer i zamknęliśmy zapisy.
Natychmiast po zapisaniu, ponieważ dane publiczne są odczytywane z tego samego źródła, które edytujecie. Nie obiecujemy natomiast szybkości aktualizacji wyników w wyszukiwarkach — to nie zależy od nas i nie możemy tego zagwarantować.
Ustala się to podczas wdrożenia: gdzie trafiają, kto je widzi, jak długo są przechowywane i czego nigdy nie należy żądać w formularzu. W klinice wiadomość często zawiera opis problemu zdrowotnego, więc nie jest „lead”, tylko kategorią danych o ścisłym reżimie — i sposób jej przetwarzania jest zapisany w opublikowanej polityce kliniki.
Tylko jeśli tego chcecie. Część naszych realizacji ma atrybucję w stopce, inne nie — zależy to od klienta. Wspominamy o tym, ponieważ to pytanie zadają kliniki i ponieważ, gdy strona nie ma żadnej atrybucji, my też nie przedstawiamy się jako autorzy bez ich zgody.
Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.