Zanim system dla sieci około 150 placówek stał się samodzielny, jego rdzeń nie należał do niego. Rejestracja, dostępność lekarzy i praca gabinetu opierały się na zewnętrznej platformie. Ten case opisuje najmniej efektowną, a najważniejszą część projektu: odcięcie się od cudzego źródła danych i zbudowanie własnego modelu — bez zatrzymywania działającej sieci.
To osobny wątek tego samego wdrożenia. Jeśli szukasz historii integracji z e-zdrowiem (P1, ZUS, NIL) i walki z e-ZLA, opisaliśmy ją w głównym case study system dla sieci placówek. Tutaj skupiamy się na tym, co było pod integracjami — na fundamencie danych.
Na starcie system nie był samodzielny. Kluczowe dane — o lekarzach, dostępności, wizytach i terminach — pochodziły z zewnętrznej platformy. Do cudzego źródła sięgały elementy, które użytkownik uznałby za „swoje": wyszukiwarka lekarzy, kalendarz, zamawianie wizyty, panel administratora i raporty.
Dla właściciela sieci placówek to wygodne na starcie i ryzykowne na dłuższą metę. Każda zmiana po stronie zewnętrznej platformy — w danych, w API, w zasadach — mogła odbić się na codziennej pracy rejestracji. A każda nowa funkcja, którą chcieliśmy dołożyć, musiała najpierw zapytać cudzy system „czy mogę".
Największa niespodzianka nie leżała w interfejsie, tylko głęboko w danych. Usługi i gabinety identyfikowane były po identyfikatorach z zewnętrznej platformy, a nie po własnych rekordach w naszej bazie. Innymi słowy: to nie był nasz model danych, tylko cień cudzego.
Konsekwencja jest poważniejsza, niż brzmi. Dopóki gabinet czy usługa „istnieje" tylko jako numer w obcym systemie, nie da się na niej bezpiecznie zbudować recepty, zwolnienia, karty pacjenta ani raportu — bo wszystko odwołuje się do znaczenia, które definiuje ktoś inny. To klasyczny vendor lock-in na poziomie danych, a nie tylko umowy.
Dlatego pierwszą realną decyzją projektową nie było „dodajmy funkcję", tylko: przenieśmy znaczenie do siebie. Zbudujmy własne tabele placówek, gabinetów i usług, i dopiero na nich stawiajmy resztę.
Każda funkcja pyta cudzy system o tożsamość własnych danych.
Tożsamość danych jest nasza. Nowa funkcja nie pyta nikogo o zgodę.
Odcięcie zaplanowaliśmy jako etapy, a nie jeden ryzykowny „wielki przełącznik" (w backlogu to m.in. zadania oznaczone jako etapy przejścia oraz osobny „cleanup" starej integracji). Sieć placówek działała przez cały czas — pacjenci wciąż się rejestrowali, lekarze przyjmowali — więc migracja musiała odbywać się pod ruchem.
Zbudowaliśmy tabele i panel do zarządzania placówkami, gabinetami i usługami lekarza: dodawanie, edycja, usuwanie. Usługę można przypisać do konkretnego gabinetu i oznaczyć jako online albo stacjonarną. Przenieśliśmy też statusy wizyt, żeby nic nie zgubiło się w trakcie przełączania.
Po kolei odpinaliśmy od zewnętrznego źródła te elementy, które użytkownik widzi na co dzień, i wskazywaliśmy je na własne tabele:
Na koniec przyszedł cleanup: refaktoryzacja kodu, uporządkowanie bazy i odpięcie starego API. To niewdzięczny etap — nie widać go w interfejsie — ale bez niego „odcięcie" zostaje tylko na papierze, a w kodzie wciąż wisi zależność, która kiedyś odezwie się w najmniej odpowiednim momencie.
Rezultat: lekarz i administrator zarządzają placówkami, gabinetami, usługami i wizytami w panelu systemu — bez zależności od zewnętrznej platformy. Dopiero na tym fundamencie dało się dołożyć integracje z P1, ZUS i NIL, kartę pacjenta i portal pacjenta.
Świadomie nie podajemy tu wskaźników procentowych — projekt nie mierzył ich w sposób, który moglibyśmy uczciwie zacytować. Dowodem jest to, że sieć około 150 placówek działa dziś na własnym rdzeniu, a znaczenie danych należy do niej, nie do zewnętrznego dostawcy.
Dopóki usługi i gabinety były opisane cudzymi identyfikatorami, każda funkcja była zakładnikiem zewnętrznego systemu. Przeniesienie znaczenia do siebie było warunkiem wszystkiego, co przyszło potem. To pierwsze pytanie, jakie warto zadać przy migracji danych pacjentów ze starego systemu: czyje są tak naprawdę identyfikatory.
Sieć placówek nie może „stanąć na weekend migracji". Dlatego odcięcie robi się etapami, z przenoszeniem statusów wizyt, a nie jednym przełącznikiem. Ryzyko rozkłada się wtedy na małe, kontrolowane kroki, a każdy z nich można spokojnie przetestować, zanim ruszy kolejny.
Odpięcie starego API i uporządkowanie bazy to nie „miły dodatek na koniec". Pominięty, zostawia ukrytą zależność, która podważa cały sens odcięcia. Traktujemy go jako pełnoprawny etap projektu.
Najtrudniejsza część migracji nie była widoczna na ekranie. Chodziło o to, żeby dane wreszcie znaczyły coś w naszym systemie, a nie były cieniem cudzego. Dopiero wtedy można było budować dalej.
Twój system medyczny opiera się na zewnętrznej platformie i chcesz się uniezależnić — albo planujesz go od zera z własnym modelem danych? Podpowiemy, od czego zacząć i gdzie są największe pułapki. Umów bezpłatną konsultację, zobacz ofertę tworzenia systemów medycznych albo główny case system dla sieci placówek.
