W tym artykule
Osiemdziesiąt procent tego systemu było gotowe, zanim padła pierwsza linijka logiki medycznej. Logowanie, role, uprawnienia, baza, formularze, powiadomienia, audyt, szyfrowanie danych pacjentów, obsługa wielu podmiotów — wszystko z pudełka. Ale najciekawsze jest to, co stało się z resztą: moduły dziedzinowe — pacjenci, konsultacje, produkcja — też nie powstały od zera.
Punkt startu: siedem aplikacji i jeden Excel
Firma pracowała rok na siedmiu aplikacjach low-code nad jedną bazą. Co dokładnie tam zastaliśmy i dlaczego migracja nie była przyznaniem się do pomyłki, opisaliśmy w tekście o granicy narzędzi wewnętrznych. W skrócie: jeden status opisywał dwa różne procesy, dane medyczne leżały czystym tekstem, technik widział PESEL pacjenta, a planowanie produkcji i tak uciekło do Excela.
Nowy system stanął na Open Mercato — otwartej platformie, na której buduje się moduły biznesowe zamiast pisać aplikację od podstaw. Tekst niżej jest o tym, jak konkretnie rozkłada się w takim wdrożeniu praca: co jest gotowe, co się dopisuje i gdzie świadomie odrzuciliśmy to, co platforma daje z pudełka.
Co dostaliśmy z platformy
Cztery rzeczy, których w systemie z danymi medycznymi po prostu nie chce się pisać ręcznie — a które są najczęstszym źródłem cichych błędów w systemach pisanych od zera:
- 1
Konta, role i uprawnienia
Centralnie sterowane: kto co widzi i kto co może zmienić. W poprzednim systemie ograniczenia trzeba było dopisywać w każdej aplikacji osobno — i wystarczyło zapomnieć w jednej, żeby cała reguła przestała obowiązywać.
- 2
Szyfrowanie danych i zarządzanie kluczami
Warstwa szyfrowania per pole razem z zarządzaniem kluczami. Dzięki temu RODO było spełnione od pierwszego dnia, a nie „dorobimy później” — co w praktyce znaczy nigdy.
- 3
Audyt, powiadomienia, dokumenty, słowniki
Historia zmian, wysyłka powiadomień, załączniki do konsultacji i administrowalne słowniki (typy ortez, materiały, działy). Wystarczyło je włączyć i podpiąć pod własne encje.
- 4
Wielopodmiotowość
System jest od początku gotowy na wiele oddziałów czy podmiotów — nie trzeba było tego przewidywać w schemacie bazy ani dokładać później, gdy pojawi się drugi punkt.
To jest ta część, którą łatwo policzyć w tygodniach zaoszczędzonej pracy. Trudniejsza do policzenia jest część druga — i to ona zaważyła na tempie wdrożenia bardziej niż gotowe logowanie.
Moduły dziedzinowe z tych samych fabryk
Platforma narzuca jeden sposób budowy każdego modułu: te same formularze, te same listy, to samo API, te same zdarzenia, ten sam mechanizm uprawnień. Programista nie projektuje kolejny raz „jak ma wyglądać lista z filtrami” — wypełnia gotowy wzorzec treścią biznesową klienta.
5 modułów dziedzinowych zbudowanych wzorcami platformy: patients kartoteka z szyfrowaniem i wyszukiwaniem po PESEL consultations kreator 6 kroków: wywiad → pomiary L/P → specyfikacja → wycena production tablica etapów warsztatu (kanban) + historia przejść planning kalendarz technik × dzień × etap, z cofaniem zmian compression_garments osobna ścieżka wyrobów uciskowych Komunikacja między modułami: tylko przez identyfikatory i zdarzenia. consultations.confirmed → powstaje zlecenie produkcyjne production.stage_changed → odświeżenie tablicy i kalendarza production.delivered → konsultacja zamknięta
Moduły nie wołają się nawzajem bezpośrednio — rozmawiają identyfikatorami i zdarzeniami. Zatwierdzenie konsultacji tworzy zlecenie produkcyjne, zmiana etapu odświeża tablicę i kalendarz, wydanie wyrobu zamyka konsultację. Dzięki temu każdy moduł da się zmienić albo wymienić bez rozbierania sąsiadów — i dokładnie tego brakowało w poprzednim rozwiązaniu, gdzie każda aplikacja pilnowała reguł na własną rękę.
Dlaczego nie użyliśmy gotowych modułów sprzedażowych
To pytanie pada zawsze, więc odpowiadamy wprost. Platforma ma gotowe moduły customers, oferty i zamówienia sprzedaży. Mapowanie wygląda kusząco: pacjent to przecież osoba, konsultacja to oferta, produkcja to realizacja zamówienia. Świadomie z tego nie skorzystaliśmy — bo rdzeń implementuje sklepowy wariant tych pojęć, a firma potrzebowała wariantu medyczno-warsztatowego.
- Pacjent to nie klient CRM. Moduł klientów jest zbudowany wokół dealów, pipeline'ów i interakcji handlowych. Pacjent ma PESEL z wyszukiwaniem po wartości zaszyfrowanej, dane o zdrowiu (art. 9 RODO) i twardą kontrolę dostępu — technik widzi inicjały i specyfikację, nie kartotekę. Własny moduł dał nam pełną kontrolę nad mapą szyfrowania i UI bez sekcji handlowych.
- Konsultacja to nie oferta. Oferta wymaga linii wskazujących produkty z katalogu, wyceny przez silnik sprzedażowy i sztywnego cyklu statusów. Konsultacja jest w dziewięćdziesięciu procentach dokumentem medycznym: około czterdziestu pomiarów na stronę, wywiad, specyfikacja warstw. Cena to dwie ręcznie wpisane kwoty. Wciśnięcie tego w ofertę oznaczałoby sztuczne produkty katalogowe i walkę z silnikiem wyceny.
- Zlecenie produkcyjne to nie zamówienie sprzedaży. Zamówienie sprzedaży jest dokumentem handlowym: linie, płatności, wysyłki. Zlecenie w warsztacie jest dokumentem wykonawczym: etapy z cofnięciami, przypisani technicy, przymiarki. To dwie różne rzeczy, które przypadkiem mają podobne nazwy.
Za to typy ortez zostały produktami katalogu — bo tam mapowanie jest trafne: każdy typ ma cenę bazową i parametry, więc kreator konsultacji potrafi policzyć wycenę i pozwolić ją skorygować ręcznie. Specyfikacja medyczna konkretnej sztuki (pomiary, warstwy) zostaje przy konsultacji. Produkt jest definicją typu, nie konfiguratorem wariantów.
RODO od pierwszego dnia, nie „dorobimy później”
Dane o zdrowiu to w RODO kategoria szczególna — wymagają szyfrowania w spoczynku. W poprzednim systemie PESEL, wywiad i adresy leżały czystym tekstem. Nie dlatego, że ktoś zaniedbał: w low-code po prostu nie ma miejsca, w którym taka warstwa mogłaby usiąść. W nowym systemie szyfrowanie musiało być aktywne, zanim zaimportowaliśmy pierwszy rekord — kolejność jest tu nienegocjowalna, bo dane wpuszczone bez szyfrowania zostają w bazie w tej postaci.
Szyfrowanie danych psuje jednak wyszukiwanie: po zaszyfrowanej kolumnie nie da się zrobić zwykłego zapytania. Dlatego obok pól zaszyfrowanych stoją kolumny z odciskiem (PESEL, e-mail, nazwisko) — pozwalają znaleźć pacjenta, nie ujawniając wartości. Do tego cztery role, z których każda widzi inny wycinek:
- Administrator — pełny dostęp.
- Koordynator — pacjenci, konsultacje, produkcja i planowanie, ale bez wywiadu medycznego.
- Ortotyk — pacjenci i konsultacje razem z wywiadem, przymiarki, planowanie tylko do odczytu.
- Technik — wyłącznie własne zlecenia, bez danych osobowych pacjenta: inicjały i specyfikacja.
Kluczowa różnica wobec poprzedniego stanu nie polega na tym, że „dodaliśmy uprawnienia”. Polega na tym, że uprawnienia są jedne, w jednym miejscu, a nie powtarzane w siedmiu aplikacjach — więc nie da się ich ominąć zapytaniem obok.
Cofanie jako funkcja pierwszej kategorii
Z rozmów z koordynatorką wyszła rzecz, której nie było na żadnej liście wymagań: najbardziej brakowało jej cofania. W poprzednim systemie każda zmiana statusu i każde przypisanie były bezpowrotne i anonimowe, a wielokrokowy formularz potrafił zgubić dane przy przeładowaniu strony. Zespół nauczył się z tym żyć — i to jest najgorszy możliwy objaw, bo znaczy, że przestali zgłaszać.
Dlatego w kalendarzu planowania każdy zapis idzie przez operację, którą da się cofnąć: skrót klawiszowy, komunikat z przyciskiem „Cofnij”, panel historii zmian. A formularz konsultacji jest kreatorem zapisującym roboczą wersję od pierwszego kroku, więc przeładowanie strony niczego nie kasuje. Obie decyzje są bezpośrednią odpowiedzią na konkretną frustrację ludzi, nie na punkt w specyfikacji.
Technik nie klika w desktopa
Ostatni element to aplikacja na tablet dla techników w warsztacie. Nikt przy stanowisku nie będzie się logował do panelu biurowego: technik bierze tablet, patrzy na swoje zlecenia, przesuwa etap i dopisuje notatkę z hali. To osobny widok, nie osobny system — ta sama baza, te same uprawnienia, ten sam audyt.
Co ważne dla tempa wdrożenia: API pod ten tablet też powstało na wzorcach platformy, a nie jako osobna warstwa integracyjna. Efekt uboczny, którego nie planowaliśmy, a który okazał się najcenniejszy przy rozwoju: każdy moduł wygląda i działa tak samo, więc nowy programista wdraża się w godziny, nie w tygodnie.
Mniej decyzji od zera
Gdyby ten system pisać od podstaw, każda z tych rzeczy byłaby osobną decyzją: jak zrobić role, jak szyfrować, jak zapisywać historię zmian, jak wygląda lista, jak nazywają się zdarzenia. Każda z nich to okazja do pomyłki — a w systemie, w którym leci PESEL dziecka i wywiad medyczny, pomyłka nie kończy się na brzydkim ekranie.
- 1
Platforma zamiast frameworka
Framework przyspiesza pisanie kodu. Platforma zdejmuje decyzje: fundament (konta, role, audyt, szyfrowanie) i sposób budowy kolejnych modułów są już rozstrzygnięte.
- 2
Gotowe moduły tylko tam, gdzie zgadza się znaczenie
Katalog produktów pasował do typów ortez, moduł klientów nie pasował do pacjentów. Wzorce z modułów referencyjnych warto brać zawsze, ale same moduły — tylko wtedy, gdy nie trzeba obchodzić ich logiki.
- 3
Najdroższy jest discovery, nie kod
Rozpoznanie procesu trwało dłużej niż implementacja pierwszych modułów. Przez rok w narzędziu low-code nikt nie musiał nazwać procesu — i ta wygoda wraca z odsetkami dopiero przy przeprowadzce.
Jeśli chcesz zrozumieć samą platformę, zacznij od wprowadzenia do Open Mercato. Jeśli natomiast zastanawiasz się, czy twoje narzędzie wewnętrzne jeszcze wystarcza — mamy o tym osobny tekst z liczbami.
Mateusz Kozłowski
Założyciel flowbiz · Ekspert automatyzacji procesów
Wdrażam automatyzacje, integracje i AI w średnich firmach na Pomorzu i w Kujawsko-Pomorskiem.
