Migracja danych pacjentów ze starego systemu: jak odciąć się od legacy bez utraty ciągłości

Migracja danych pacjentów to nie „eksport-import" — to przeniesienie danych i jednoczesne odłączenie wszystkich miejsc, które z nich korzystają, bez przerywania pracy placówki. Największa praca nie leży w skopiowaniu rekordów, lecz w odnalezieniu każdej zależności od starego systemu i przepięciu jej na nowe źródło. Ten artykuł pokazuje, jak zrobić to bezpiecznie — na podstawie realnego wdrożenia.

Rekordy przenosi się szybko. Zależności — nie. I to one decydują o powodzeniu migracji.

Czy ten artykuł jest dla Ciebie?

Będzie pomocny, jeśli:

• zmieniasz system w przychodni lub klinice na nowy,
• budujesz dedykowany system i musisz przenieść dane ze starego,
• jesteś dyrektorem IT / decydentem i boisz się przestoju oraz utraty danych,
• chcesz zrozumieć, dlaczego migracja bywa najdroższą częścią wymiany systemu.

Jeśli szukasz gotowego skryptu „przenieś tabelę A do B" — to nie tutaj. Pokazujemy podejście, które chroni ciągłość pracy i dane pacjentów, a nie pojedyncze zapytanie SQL.

Co naprawdę znaczy migracja i „odcięcie od legacy"

W starym systemie dane i funkcje są zwykle splecione: wyszukiwanie lekarzy, dane w kalendarzu, umawianie wizyt czy statusy — wszystko potrafi pobierać dane z jednego, wspólnego źródła. Migracja to moment, w którym budujesz własne źródło prawdy i przepinasz do niego wszystkie te punkty, a na końcu odłączasz stary system tak, by w kodzie nie został ani jeden punkt, który wciąż go potrzebuje.

To dlatego migracja jest częściej problemem architektury niż transferu danych. Sam transfer bywa szybki — ale jeśli wiele miejsc w aplikacji nadal czyta ze starego systemu, migracja nie jest skończona.

Czego nauczyło nas wdrożenie

Portal systemu dla sieci placówek medycznych zbudowaliśmy w praktyce od podstaw — projekt objął ponad 450 zadań w ciągu około półtora roku, dla środowiska rzędu 150 placówek, 40 lekarzy i ~100 gabinetów. Jednym z trudniejszych etapów było odcięcie od poprzedniego, zewnętrznego portalu. Oto co z tego wynieśliśmy:

Założenie: „migracja = eksport danych pacjentów i import do nowej bazy".

Rzeczywistość: najtrudniejsze nie było przeniesienie rekordów, lecz inwentaryzacja i przepięcie wszystkich zależności. Ze starego portalu dane pobierało co najmniej sześć obszarów aplikacji: rejestracje, dostępność, wizyty i terminy, wyszukiwarka (filtry + search), raporty i panel administratora. Do tego niespodzianka, która zmieniła plan: usługi i gabinety były w kodzie identyfikowane po ID ze starego systemu, nie po własnych rekordach — więc zanim cokolwiek przepięliśmy, musieliśmy zbudować własny model danych (placówki, gabinety, usługi) i przenieść na niego statusy wizyt. Odcięcie zamknął osobny etap — refaktoryzacja kodu, wyczyszczenie bazy i odpięcie API — po którym w systemie nie było już żadnego połączenia ze starym portalem.

Wniosek: migracja kończy się nie w momencie skopiowania danych, lecz gdy ostatnia zależność od starego systemu zostaje odłączona — i potwierdzona testem, że nic już go nie woła.

Etapy migracji z minimalnym oknem przełączenia

• Backup i punkt odtworzenia — pełna, przetestowana kopia stanu sprzed migracji. Pierwszy krok, nie ostatni.
• Inwentaryzacja zależności — spis wszystkich tabel, funkcji i punktów zależnych od starego systemu (zwykle największe zaskoczenie).
• Nowy model danych — własne tabele i interfejsy jako nowe źródło prawdy.
• Migracja próbna (dry-run) na kopii, przed produkcją.
• Migracja i porządkowanie jakości danych — pacjenci, wizyty, statusy, słowniki. Porządkowanie jakości to nie kasowanie — dokumentacja medyczna podlega ustawowej retencji (o tym niżej).
• Walidacja kompletności i poprawności (reconciliation) — liczności rekordów, sumy kontrolne, spójność referencyjna (wizyta → pacjent → lekarz), poprawność dat i statusów. To osobny etap od odcięcia: potwierdza, że dane przeszły w komplecie i we właściwe miejsca.
• Przepięcie źródeł — każde miejsce w aplikacji czyta już z nowej bazy.
• Okres przejściowy i kryteria go/no-go — nowe działa równolegle; stare odłączamy dopiero po potwierdzeniu, że nowe źródło jest zweryfikowane.
• Weryfikacja odcięcia od legacy — potwierdzenie, że w kodzie i w ruchu nie ma już połączenia ze starym systemem.
• Cutover z planem wycofania (rollback) — przełączenie w zaplanowanym oknie, z jasną ścieżką powrotu, bez luki w rozliczeniach NFZ.

Najczęstsze pułapki

• Niedoszacowanie zależności ukrytych — „to tylko przenieść dane" kończy się odkryciem dziesiątek miejsc czytających ze starego systemu.
• Brak okresu przejściowego — odłączenie starego, zanim nowe jest w pełni sprawdzone.
• Jakość danych — bałagan w starej bazie przenosi się do nowej, jeśli go nie posprzątać.
• Ciągłość NFZ i rejestracji — migracja nie może zostawić luki w rozliczeniach ani w obsłudze pacjentów.
• Pominięcie RODO — dane pacjentów to dane wrażliwe, a nie „zwykłe rekordy".

Najdroższa migracja to ta, którą trzeba powtórzyć — bo za pierwszym razem nie odcięto starego systemu do końca.

Red flags: kiedy uciekać od wykonawcy

• obiecuje migrację „w jedną noc" bez inwentaryzacji zależności,
• nie pyta, co jeszcze korzysta ze starego systemu,
• nie ma okresu przejściowego ani planu wycofania (rollback),
• pomija jakość danych i RODO,
• nie potrafi udowodnić, że po migracji nic już nie łączy się z legacy.

Dane pacjentów a RODO i retencja

Dane o zdrowiu należą do szczególnych kategorii danych osobowych (art. 9 RODO), potocznie zwanych wrażliwymi — dlatego migracja podlega podwyższonym wymogom. W praktyce to m.in.:

• Role i umowa powierzenia — placówka jest administratorem, wykonawca migracji podmiotem przetwarzającym; stąd umowa powierzenia (art. 28 RODO).
• DPIA — przetwarzanie danych zdrowotnych na dużą skalę zwykle wymaga oceny skutków (art. 35 RODO).
• Minimalizacja, szyfrowanie, logowanie oraz pseudonimizacja w środowiskach testowych — nie migruj realnych danych pacjentów do dev/test.
• Retencja dokumentacji medycznej — co do zasady 20 lat (art. 29 ustawy o prawach pacjenta), z wyjątkami (m.in. 30, 22, 10, 5 lat). Skutek praktyczny: dokumentacji objętej retencją nie wolno usuwać przy okazji „porządkowania" danych.

Dobra wiadomość: migracja w ramach tego samego administratora i celu nie wymaga nowej zgody pacjentów. Zakres wymogów zależy jednak od skali i wyniku analizy ryzyka — dlatego bezpieczeństwo planuje się na równi z techniką migracji.

Artykuł opisuje doświadczenie wdrożeniowe i nie stanowi porady prawnej — kwestie RODO skonsultuj z IOD lub prawnikiem.

FAQ

Czym jest migracja danych pacjentów?

To przeniesienie danych (pacjenci, wizyty, dokumenty, słowniki) ze starego systemu do nowego oraz przepięcie wszystkich miejsc, które z tych danych korzystają. Najtrudniejsze jest zwykle nie skopiowanie rekordów, lecz odnalezienie i odłączenie zależności od starego systemu.

Czy można zmienić system bez przestoju?

Zwykle z minimalnym, zaplanowanym oknem przełączenia — w zależności od architektury i wielkości danych. Kluczowe, by rozliczenia z NFZ i praca rejestracji nie miały luki, dlatego cutover planuje się w spokojniejszym oknie i z planem wycofania.

Co z ochroną danych pacjentów podczas migracji?

To szczególne kategorie danych (art. 9 RODO): minimalizacja dostępu, szyfrowanie, logowanie, umowa powierzenia (art. 28), zwykle DPIA (art. 35) i pseudonimizacja w środowiskach testowych. Dokumentacja podlega też ustawowej retencji.

Ile trwa migracja danych medycznych?

Zwykle decyduje złożoność zależności i jakość danych, choć przy dużych wolumenach (np. dokumentacja obrazowa) znaczenie ma również ilość danych. Największą pracą bywa inwentaryzacja i przepięcie źródeł, a nie samo skopiowanie tabel.

Co dalej

Nie każda wymiana systemu wymaga wielkiego projektu — czasem wystarczy dobrze zaplanowany eksport i import. Ale gdy stary system jest spleciony z całą aplikacją, migracja staje się projektem architektonicznym, i lepiej to wiedzieć wcześniej.

Warto też przeczytać:

• Ile kosztuje oprogramowanie dla przychodni — dlaczego migracja to często największy koszt
• Integracja z P1 (e-Recepta, e-Skierowanie)
• AI i systemy dla ochrony zdrowia

Dowody i doświadczenia

3 rzeczy, które zrobilibyśmy dziś inaczej

Najuczciwszy dowód doświadczenia to nie lista sukcesów, lecz to, co poprawilibyśmy, wiedząc, co wiemy teraz:

1. Pełna inwentaryzacja zależności przed pierwszą linijką migracji. To ona, a nie transfer danych, wyznacza realny harmonogram. Każdy pominięty punkt czytający ze starego systemu wraca później jako niespodzianka przy cutoverze.
2. Własny model danych od dnia zero, niezależny od ID z legacy. U nas usługi i gabinety były identyfikowane po ID ze starego systemu — gdybyśmy zaprojektowali własne identyfikatory od początku, oszczędzilibyśmy sobie osobnego etapu przemodelowania.
3. Reconciliation jako zaplanowany etap, nie czynność „na końcu". Walidacja kompletności decyduje, kiedy naprawdę wolno odciąć legacy. Wpisana w plan z góry, a nie doklejona przed cutoverem, zdejmuje najwięcej ryzyka.