Infrastruktura placówki: gdzie działa system, kopie, sieć i sprzęt bez poprawek

Przychodnia z czterema gabinetami, poniedziałek w lipcu, 7:30. Rejestracja nie może otworzyć terminarza. Serwer stoi w dawnym schowku, którego drzwi zwykle są uchylone, bo inaczej robi się tam gorąco. W piątek ktoś je domknął, a w niedzielę serwer wyłączył się sam, żeby się nie spalić. Nikt o tym nie wiedział, bo nic nie wysyła powiadomień, a jedyny klucz do szafy ma informatyk, który przyjeżdża we wtorki. Gdy przyjeżdża wcześniej, serwer wstaje z jednym uszkodzonym dyskiem, a baza nie chce się uruchomić. Kopia robiła się co noc i w piątek była zielona, tylko leży na dysku w tej samej szafie, nie obejmuje skanów skierowań, a hasło do niej jest w pliku na serwerze, który właśnie nie działa. Do południa rejestratorki zapisują pacjentów na kartce.

Nikt w tej przychodni nie zaniedbał niczego wielkiego. Zabrakło zwykłych rzeczy: klimatyzacji pracującej w weekend, powiadomienia do dwóch osób, kopii poza budynkiem, testu odtworzenia i drugiej osoby, która zna hasła. Każda z nich ma tę samą budowę: potrzebuje właściciela z nazwiska, daty w kalendarzu i próby, którą ktoś naprawdę przeprowadził. Bez próby placówka wie, że coś ma, ale nie wie, czy to zadziała.

Dla kogo i jak czytać. Gabinet z programem w abonamencie przeczyta pierwszy rozdział, części o aktualizacjach i certyfikatach, a resztę znajdzie w skrócie w rozdziale Co to znaczy na waszej skali. Przychodnia z własnym serwerem przechodzi przez rozdziały o serwerowni, kopiach, systemach bez wsparcia i aktualizacjach, a przychodnia w chmurze zaczyna od pierwszego rozdziału i od testu kopii u dostawcy. Sieć przychodni dokłada rozdział o sieci i łączach. Szpital potrzebuje całości, a sieć szpitali czyta każdy rozdział pod kątem jednego wzoru dla wszystkich szpitali. Terminy i przepisy podaję według stanu na 29.09.2026.

SaaS, serwer lokalny czy chmura prywatna: kto co trzyma

SaaS to system w abonamencie, uruchamiany w przeglądarce: serwery, baza, kopie i aktualizacje są po stronie dostawcy. Serwer lokalny stoi w budynku placówki, która kupuje licencje systemu, bazy danych i systemu operacyjnego, sprzęt i oprogramowanie do kopii, a utrzymanie spada na jej informatyka albo firmę serwisową. Chmura prywatna to infrastruktura dla jednej placówki albo jednej sieci w centrum danych operatora albo w serwerowni jednej z lokalizacji; sprzętem zajmuje się operator, systemem dostawca, a decyzje o kopiach, aktualizacjach i dostępie zostają w placówce.

Żaden model nie przenosi odpowiedzialności. Placówka jest administratorem danych pacjentów i korzysta tylko z podmiotów przetwarzających, które dają wystarczające gwarancje (art. 28 ust. 1 RODO). Administrator ma umieć wykazać zgodność (art. 24 ust. 1 RODO), więc także to, że z kopii da się wrócić. W SaaS poproście dostawcę o protokół ostatniego testu odtworzenia albo pisemną odpowiedź, kiedy ostatnio odtworzył bazę i czy kopia leży w innym miejscu niż baza produkcyjna, a do tego o kraj, w którym stoją serwery i kopie, i o dziennik dostępu jego pracowników do danych. Umowa powierzenia musi zobowiązywać dostawcę do udostępniania informacji potrzebnych do wykazania zgodności i do umożliwienia audytów (art. 28 ust. 3 lit. h RODO); pozostałe zapisy są w rozdziale Umowa powierzenia.

Bez łącza SaaS nie działa: rejestracja nie widzi grafiku, lekarz historii pacjenta. Przychodnia potrzebuje drugiego łącza od innego operatora (rozdział Sieć, Wi-Fi i łącza), grafiku drukowanego wieczorem na następny dzień i odpowiedzi dostawcy, czy system ma tryb odczytu bez połączenia. Serwer lokalny chroni przed awarią łącza tylko w budynku, bo e-recepta, e-skierowanie i zdarzenia medyczne i tak idą do P1 przez internet; przychodnia, która trzyma serwer z obawy o łącze, powinna uczciwie policzyć, przed czym on ją chroni. W chmurze prywatnej sieci najsłabszym punktem jest łącze lokalizacji do centrum danych. Ile danych i godzin placówka może stracić, rozstrzyga dyrektor albo właściciel, co opisuję w rozdziale RPO i RTO, a pracę bez łącza w rozdziale Przychodnia i gabinet bez internetu.

Oferta SaaS nie obejmuje urządzeń w placówce. Drukarka etykiet w punkcie pobrań, czytnik kodów, skaner, aparat EKG zapisujący wynik do karty czy analizator własnego laboratorium potrzebują programu pośredniczącego albo integracji po stronie dostawcy, więc przed wyborem spiszcie urządzenia i przy każdym ustalcie z dostawcą, jak zadziała. Certyfikaty do P1 i podpisu w SaaS przechowuje zwykle dostawca; placówka powinna wiedzieć, gdzie są, a przy zmianie dostawcy nowy system musi je mieć przed dniem przełączenia.

Modele porównujcie na pięć lat razem z kosztem wyjścia, według rozdziału Dziesięć pozycji kosztu. Dane wprowadzone do systemu i w nim wytworzone należą do placówki, oprogramowanie jest na licencji, a warunki wyjścia zapisuje się przed podpisaniem umowy (Dane i wyjście). Od 12 stycznia 2027 dostawca usług chmurowych nie pobiera opłat za samą zmianę dostawcy (art. 29 ust. 1 rozporządzenia (UE) 2023/2854), ale zakaz nie obejmuje usług, których większość głównych cech opracowano na zamówienie jednego klienta i które nie są oferowane na szeroką skalę (art. 31 ust. 1). Taka może być chmura prywatna zbudowana dla jednej sieci, więc tam warunki wyjścia negocjuje się w umowie (Zmiana dostawcy chmury).

Serwerownia w przychodni: minimum, które wystarcza

Serwerownia to koszt w czasie: prąd, klimatyzacja, baterie, człowiek z kluczem. Przy systemie w abonamencie zostaje zamykana szafka z routerem i przełącznikiem, więc ten rozdział jest dla przychodni, która serwer ma albo świadomie go zostawia.

Przepisy nie mówią, jak ma wyglądać serwerownia, tylko co ma być zapewnione: ochrona dokumentacji przed zniszczeniem, uszkodzeniem, utratą i dostępem osób nieupoważnionych oraz jej wykorzystanie bez zbędnej zwłoki (§ 1 ust. 7 rozporządzenia Ministra Zdrowia w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania), dbałość o aktualizację oprogramowania i okresowa ocena skuteczności zabezpieczeń (§ 1 ust. 5 pkt 4 i 5), ciągła dostępność systemów i szybkie przywrócenie danych po incydencie fizycznym lub technicznym (art. 32 ust. 1 lit. b i c RODO), a takim incydentem jest przegrzany serwer. Informatyk z dostępem do serwera działa na podstawie upoważnienia administratora (art. 24 ust. 2 pkt 2 ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta).

Pomieszczenie i klucz. Zamykane pomieszczenie albo szafa, do której wchodzą tylko osoby z listy. Klucz ma informatyk i jedna osoba na miejscu, drugi leży w sejfie, a serwisant klimatyzacji czy sprzątanie wchodzą w obecności kogoś z listy. Serwer pod biurkiem rejestracji minimum nie spełnia: pacjent stoi obok, ktoś wkłada pendrive, przycisk zasilania jest na wysokości kolan. Taki serwer trafia do zamykanej szafy, choćby małej wiszącej na zapleczu. Szafa nie stoi pod rurami z wodą, w piwnicy zalewanej przy ulewie ani w pomieszczeniu socjalnym.

Zasilanie. UPS ma dać serwerowi czas na spokojne wyłączenie. Podłączcie do niego serwer, przełącznik i router, bo serwer na baterii przy zgaszonym przełączniku pracuje, tylko nikt się z nim nie połączy. UPS musi być połączony z serwerem kablem albo przez sieć, a próba przy zamkniętej przychodni pokazuje, czy serwer i dysk sieciowy z kopią zamykają się same z zapasem baterii. Drukarka laserowa i czajnik do UPS nie trafiają, a termin wymiany baterii podany przez producenta stoi w kalendarzu informatyka.

Temperatura i powiadomienia. Zakres temperatur podaje dokumentacja producenta serwera. Klimatyzator pracuje w weekendy i nie ma go na wspólnym wyłączniku z zapleczem, bo uchylone drzwi nie są chłodzeniem. Czujnik temperatury wysyła mail albo SMS do dwóch osób, które w sobotę mogą przyjechać. Te same dwie osoby dostają powiadomienia kontrolera dysków i UPS o awarii dysku, pracy na baterii i zużytej baterii, bo serwer z dwoma dyskami w macierzy RAID pracuje dalej po awarii jednego, a pomarańczowej diody na obudowie nikt nie ogląda. Raz na kwartał informatyk sprawdza, czy próbne powiadomienie dochodzi, a w umowie z informatykiem z zewnątrz stoi, kto czyta powiadomienia i w jakim czasie reaguje.

Zdalny dostęp i sprzęt. Karta zdalnego zarządzania serwerem pozwala go zrestartować bez przyjazdu i w scenie z początku skróciłaby przestój o dzień, ale informatyk łączy się z nią tylko przez VPN, na własnym koncie, z hasłem innym niż fabryczne. W kalendarzu obok baterii stoi koniec gwarancji serwera i koniec wsparcia systemu i bazy z rozdziału Systemy bez wsparcia. Kopia na dysku w tej samej szafie przepadnie przy zalaniu, pożarze i szyfrowaniu, więc minimum to kopia poza budynkiem i druga niepodłączona stale do sieci.

Karta serwerowni. Jedna strona na drzwiach od wewnątrz i w segregatorze kierownika: gdzie są klucze i kto jest na liście, numer do informatyka i jego zastępcy, do serwisu dostawcy systemu i operatora łącza, kolejność wyłączania i włączania urządzeń, koniec gwarancji serwera, ostatnia wymiana baterii i ostatni test odtworzenia. Haseł na niej nie ma.

Wersja szpitalna. Dla szpitala ta lista to sprawdzian rzeczy prostych: kto ma klucze, czy powiadomienia o temperaturze dochodzą w nocy, czy kopia leży poza budynkiem. Podmiot kluczowy albo ważny zapewnia bezpieczeństwo fizyczne i środowiskowe z kontrolą dostępu oraz wdraża, dokumentuje, testuje i utrzymuje plany ciągłości działania, plany awaryjne i plany odtworzenia działalności (art. 8 ust. 1 pkt 2 lit. c i f ustawy o KSC w brzmieniu nowelizacji Dz.U. 2026 poz. 252); terminy są w rozdziale Kalendarz KSC. W szpitalu specjalistycznym i w sieci szpitali kopia albo zapasowy sprzęt stoją w innym budynku niż serwerownia główna.

Kopia zapasowa, która się odtwarza: test w jedno popołudnie

Zielony raport z programu do kopii, taki jak piątkowy w przychodni z początku, mówi, że powstał plik, a nie że pielęgniarka otworzy z niego kartę pacjenta. RODO i rozporządzenie o dokumentacji medycznej, przywołane w rozdziale o serwerowni, wymagają zdolności przywrócenia danych i okresowej oceny zabezpieczeń także od jednoosobowego gabinetu. Podmiot kluczowy albo ważny testuje dodatkowo plany odtworzenia (art. 8 ust. 1 pkt 2 lit. f ustawy o KSC). Centrum e-Zdrowia w rekomendacjach dotyczących kopii zaleca cykliczne testy odtworzenia w izolowanym środowisku i kopie odseparowane od sieci.

Przepisy nie podają częstotliwości testu; rytm ustala polityka na podstawie analizy ryzyka. W praktyce szpital co kwartał odtwarza inny system krytyczny, na przykład szpitalny, laboratoryjny, apteczny i kadrowo-płacowy, więc każdy przechodzi test co najmniej raz w roku, a od ostatniego testu któregokolwiek systemu krytycznego nie mija więcej niż pół roku. Przychodnia z własnym serwerem przechodzi tę samą procedurę dla swojego systemu. Przychodnia w chmurze prosi dostawcę o odtworzenie kopii jej danych na osobnej instancji i sprawdza pięć kart, a dowodem jest protokół dostawcy z godzinami; umowa przewiduje taki test, a gdy dostawca odmawia, minimum to pełny eksport danych i odczytanie z niego tych samych pięciu kart. Przed testem zapiszcie dwa cele, ile godzin może trwać powrót do pracy i z ilu godzin placówka może stracić wpisy, ustalone przez dyrektora według rozdziału RPO i RTO.

Tydzień przygotowania

Wybierzcie jeden system i przygotujcie osobny serwer albo maszynę wirtualną bez połączenia z siecią produkcyjną, w przychodni zwykle drugi komputer odpięty od sieci. Odtworzony system, który widzi internet, może drugi raz wysłać zdarzenia medyczne do P1 albo przypomnienia SMS. Przy logowaniu przez domenę, co w szpitalu jest regułą, w izolowanej sieci potrzebny jest kontroler domeny z kopii albo konta lokalne.

Na test zgadza się kierownik IT, a w przychodni kierownik albo właściciel, razem z inspektorem ochrony danych, jeśli placówka go wyznaczyła, i ustalają, kto zobaczy odtworzone dane i kiedy zostaną usunięte. Dostęp mają osoby wykonujące zawód medyczny oraz informatycy na podstawie upoważnienia administratora (art. 24 ust. 2 ustawy o prawach pacjenta). Kopię wskazuje ktoś spoza zespołu, który ją robi, bo ten odruchowo wybierze tę, o której wie, że jest dobra, i to z nośnika odseparowanego od sieci, z którego odtwarzalibyście po ataku. Raz w roku wskazuje kopię sprzed kilku tygodni, bo atakujący bywa w sieci długo przed zaszyfrowaniem danych i najświeższe kopie mogą być skażone.

Od dostawcy potrzebna jest licencja na drugi serwer, klucze, instrukcja i osoba pod telefonem, a umowa powierzenia przewiduje jego pomoc w obowiązkach z art. 32 RODO (art. 28 ust. 3 lit. f RODO). Osobę, która sprawdzi karty, wpiszcie do grafiku, a z produkcji weźcie raport na godzinę kopii z liczbą dokumentów i numerem ostatniego wpisu.

Popołudnie z zegarkiem

Test zaczyna się o ustalonej godzinie, na przykład 13:00, i od tej chwili produkcji nie ma: nikt nie zagląda na działający serwer po brakujący plik ani hasło. Każdy krok ma w protokole godzinę: nośnik podłączony, hasło i klucz wyjęte z sejfu, serwer gotowy, baza odtworzona, pliki spoza bazy odtworzone, aplikacja przyjęła licencję, pierwszy użytkownik zalogowany na zwykłe konto. Odtworzenie prowadzi osoba według spisanej procedury, a jeśli procedurę zna tylko jedna osoba, prowadzi ktoś inny. Przed otwarciem kart informatyk uruchamia kontrolę spójności bazy narzędziem producenta silnika bazy danych.

Sukcesu nie ogłasza informatyk po starcie usługi. Ogłasza go pielęgniarka, lekarz albo rejestratorka, która otwiera pięć losowych kart pacjentów z różnych oddziałów albo poradni i porównuje z produkcją wpisy sprzed godziny kopii: wynik badania, opis obrazu, zlecenie leku, dokument podpisany elektronicznie. Do tego raport zgodny ze stanem sprzed testu, otwierające się załączniki i ostatni wpis z godziną zgodną z czasem kopii. Czas od ogłoszenia awarii do końca weryfikacji to rzeczywisty czas odtworzenia, a odstęp między kopiami to najgorszy przypadek utraty danych.

Test jest zaliczony, gdy oba cele są spełnione, pięć kart się zgadza, pliki się otwierają, a procedura przeszła bez improwizacji. Warunkowo zaliczony, gdy cele są spełnione, ale były odstępstwa od procedury albo braki poza danymi pacjentów. Niezaliczony, gdy cel przekroczono, karta jest niezgodna albo brakuje plików; wynik trafia do kierownika podmiotu, a test powtarzacie po poprawkach.

Co musi być w kopii

Obok bazy w kopii muszą być skany i wyniki w PDF, konfiguracja, plik licencji i certyfikaty do P1, bo inaczej baza wstaje, a lekarz widzi odnośniki do nieistniejących dokumentów i nie wystawi e-recepty. Hasło do repozytorium, klucz szyfrowania kopii i certyfikat szyfrowania samej bazy mają osobne kopie w sejfie. Bazę kopiuje się mechanizmem, który silnik bazy danych uznaje za spójny, a nie migawką maszyny wirtualnej w trakcie pracy bazy.

Po teście

Środowisko testowe wyłączacie tego samego dnia, a odtworzone dane usuwacie, bo zapomniany serwer testowy z danymi pacjentów to ryzyko dla poufności (art. 5 ust. 1 lit. f RODO). Protokół trafia do dokumentacji bezpieczeństwa i do inspektora ochrony danych; pozwala wykazać przestrzeganie RODO (art. 5 ust. 2), a w podmiocie kluczowym albo ważnym jest dokumentacją operacyjną (art. 10 ust. 4 ustawy o KSC). Na końcu trzy pola: co poszło inaczej niż w procedurze, jakie poprawki, kto i do kiedy je wprowadzi, i który system testujecie następnym razem. Wzór na dwie strony A4 to Protokół testu odtworzenia kopii, wypełniany ręcznie, godzina po godzinie.

Sieć, Wi-Fi i łącza: gdzie zaczynają się awarie systemu

Gdy oddział zgłasza, że system się zawiesza, a dostawca po sprawdzeniu serwera odpowiada, że pracuje bez zarzutu, obie strony zwykle mówią prawdę. Przyczyna leży po drodze: w punkcie dostępowym Wi-Fi powieszonym, gdy na oddziale był jeden komputer, w przełączniku bez zasilania awaryjnego w pomieszczeniu gospodarczym albo w jedynym łączu do internetu. W projektach, które prowadziłem w szpitalach, zgłoszenie „system się zawiesza” wiele razy kończyło się w szafie na piętrze, a nie na serwerze.

Droga od łóżka do serwera

Każde kliknięcie przechodzi drogę: stanowisko albo tablet, gniazdo albo punkt dostępowy, przełącznik na piętrze, połączenie między budynkami, serwerownia, a dla e-recepty i usług w chmurze jeszcze łącze i P1. Dostawca systemu odpowiada za aplikację i często za serwer, operator za łącze do granicy budynku, a sieć wewnątrz szpitala zwykle nie ma właściciela w żadnej umowie, więc zgłoszenie krąży między firmami. Narysujcie tę drogę dla jednego oddziału i przy każdym elemencie zapiszcie, kto go serwisuje, ile ma lat, czy ma zasilanie awaryjne, a przy przełącznikach, czy są zarządzalne i do kiedy producent wydaje poprawki. Najwięcej odcinków bez właściciela powstaje przy remontach, więc gniazda i punkty dostępowe informatyk uzgadnia przed zamknięciem sufitów, a remontu nie odbiera się bez dokumentacji powykonawczej okablowania z pomiarami.

Pięć informacji w zgłoszeniu rozstrzyga w kilka minut, gdzie szukać: godzina, numer stanowiska albo wózka, sala, kabel czy Wi-Fi i to, czy stanowisko obok działa w tej samej chwili. Przełączniki, punkty dostępowe i UPS w szafach obejmuje się monitorowaniem dostępności, które powiadamia informatyka, zanim zadzwoni oddział. To inna sprawa niż nocne pilnowanie bezpieczeństwa z rozdziału Kto wykrywa w nocy, ale oba powiadomienia muszą mieć odbiorcę.

Szafy na piętrach i Wi-Fi

Serwerownia ma UPS, klimatyzację i zamek, szafy na piętrach często nic z tego. Przy zaniku prądu serwer pracuje, a oddział go nie widzi, bo przełącznik zgasł razem ze światłem na korytarzu, a latem sprzęt w szafce bez wentylacji zaczyna się restartować. Test baterii polega na odłączeniu zasilania szafy w uzgodnionym oknie i zmierzeniu, ile minut przełącznik pracuje na baterii, w porównaniu z czasem, w którym agregat przejmuje zasilanie.

Z Wi-Fi projektowanego dla gości korzystają dziś wózki z komputerami, tablety, czytniki kodów przy podawaniu leków i część urządzeń medycznych. Pomiar robi się w czasie pracy oddziału: przejście z laptopem trasą obchodu, sala po sali, z zapisem siły sygnału i miejsc, gdzie połączenie się zrywa. Jedno hasło do sieci personelu, znane studentom i byłym pracownikom, zastępuje się logowaniem kontem pracownika albo certyfikatem urządzenia, żeby wyłączyć jedno konto bez przestawiania każdego tabletu. Producent wyrobu medycznego z oprogramowaniem określa minimalne wymogi sieci i bezpieczeństwa informatycznego (załącznik I pkt 17.4 rozporządzenia (UE) 2017/745), więc zbiera się je przed zmianą konfiguracji Wi-Fi, a nie po telefonie z intensywnej terapii.

Płaska sieć i łącza na zewnątrz

W płaskiej sieci komputery administracji, stanowiska kliniczne, kamery, drukarki i aparatura są razem. Jeden źle wpięty kabel potrafi utworzyć pętlę, która zatrzymuje sieć w całym budynku, a złośliwe oprogramowanie z sekretariatu widzi serwer bazy danych. Podział sieci według przeznaczenia ogranicza obie szkody. Ustawa o KSC przewiduje czasowe ograniczenie ruchu przychodzącego do infrastruktury po dostrzeżeniu podatności lub cyberzagrożeń, z uwzględnieniem skutków dla dostępności usług (art. 8 ust. 1 pkt 5 lit. d ustawy o KSC), a w płaskiej sieci łatwo przy tym odciąć cały szpital.

Jedno łącze od jednego operatora to pojedynczy punkt awarii dla e-recepty, P1, wyników z laboratorium i zdalnego serwisu. W szpitalu drugie łącze pochodzi od innego operatora i wchodzi do budynku inną drogą fizyczną, bo dwa kable w jednym kanale uszkodzi ta sama koparka. W przychodni wystarcza router z kartą SIM innej sieci, a comiesięczną próbę, czy przejmuje ruch do P1, opisuję w rozdziale Przychodnia i gabinet bez internetu. W szpitalu przełączenie na łącze zapasowe też sprawdza się raz w miesiącu, w zaplanowanym oknie, i wpisuje do planu ciągłości działania.

Awaria sieci nie musi być atakiem, żeby w podmiocie kluczowym albo ważnym liczyła się w ustawie o KSC: incydent to zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów, w tym dostępność usług (art. 2 pkt 3d i 5), a poważne obniżenie jakości albo przerwanie ciągłości usługi czyni go incydentem poważnym (art. 2 pkt 7). Klasyfikuje go sam podmiot na podstawie progów uznania incydentu za poważny, określanych w rozporządzeniu Rady Ministrów (art. 11 ust. 1 pkt 3 i ust. 4), więc sposób ich stosowania do własnych usług spisuje się przed pierwszą awarią, a terminy zgłoszeń są w rozdziale Dwa zegary. Przełącznik w schowku jest aktywem tak samo jak serwer, a operator łącza i firma od sieci należą do łańcucha dostaw (art. 8 ust. 1 pkt 2 lit. e i m).

Systemy bez wsparcia: Windows 10, SQL Server 2016, Windows Server 2016

Komputer bez poprawek nie przestaje działać. Przestaje być bezpieczny, i nikt tego nie widzi na ekranie. Po końcu wsparcia producent nie wydaje poprawek bezpieczeństwa ani nie udziela pomocy technicznej.

Daty według stron cyklu życia Microsoftu, stan na 29.09.2026. Dla Windows 10 lata są kumulatywne, cena katalogowa pierwszego roku to 61 USD za urządzenie i podwaja się co roku, a każdy rok wymaga osobnej aktywacji na każdym komputerze. ESU dla SQL Server 2016 na własnym serwerze wymaga podłączenia instancji do Azure Arc i Software Assurance albo rozliczenia godzinowego, a pomocy technicznej nie przywraca.

Spis komputerów w tydzień

Przychodni wystarczy pięć dni i osoba, która wejdzie do każdego pomieszczenia; szpital dzieli plan na budynki. Pierwszy dzień to eksport komputerów z domeny albo konsoli antywirusa, drugi obchód po komputerach spoza domeny, przy aparatach, drukarkach etykiet i centralach telefonicznych. Trzeci to wydanie, wersja (22H2 to kompilacja 19045), stan ESU z polecenia slmgr.vbs /dlv i data ostatniej aktualizacji zbiorczej, czwarty opis, do czego służy każdy komputer bez wsparcia i czy ma internet. Piąty to decyzja przy każdym: Windows 11 albo wymiana, drugi rok ESU jako most z datą końca, odcięcie od sieci albo wycofanie, z osobą i terminem. Windows 11 wymaga TPM 2.0 i procesora z listy Microsoftu, a przed wymianą dwudziestu stanowisk sprawdza się na jednym system medyczny, czytniki i drukarki.

Komputer przy tomografie, USG albo analizatorze to osobna sprawa, bo program producenta bywa dopuszczony do jednej wersji systemu, a zmianę robi jego serwis. Producent odpowiada na piśmie, jakie wydanie jest na komputerze, do kiedy je wspiera i czy planuje aktualizację; pytania są w materiale Pytania do dostawcy oprogramowania medycznego. Do tego czasu komputer dostaje odcięcie według rozdziału Urządzenia medyczne.

Serwer bazy danych

Koszt migracji to licencje nowych wersji, praca ludzi i sprzęt na czas pracy dwóch serwerów obok siebie, a każda pozycja może mieć innego płatnika. Odpowiedź zaczyna się w umowie z dostawcą systemu: kto jest licencjobiorcą SQL Server i czy utrzymanie obejmuje dostosowanie aplikacji do nowych wersji środowiska. W części modeli biznesowych dużych dostawców aktualizacja środowiska to osobna oferta spoza opłaty za utrzymanie. Następna umowa mówi wprost o obowiązku utrzymywania aplikacji na wspieranych wersjach bazy i systemu (Lista kontrolna umowy z dostawcą).

Dostawca potwierdza na piśmie: na jakich wersjach dopuszcza obecną i najnowszą wersję aplikacji, czy migracja bazy wymaga aktualizacji aplikacji, co poza bazą leży na serwerze (zadania nocne, raporty, integracje z laboratorium i P1), czy stacje potrzebują nowych sterowników, kto migruje i testuje oraz jak wygląda powrót. Najpierw zmienia się serwer, a poziom zgodności bazy dopiero po testach. Propozycja przejścia na SQL Server 2017 albo Windows Server 2019 oznacza powtórkę projektu za rok albo dwa.

Nowy serwer stawia się obok starego, bo aktualizacja w miejscu odbiera drogę powrotu. Przepięcie trwa minuty, gdy aplikacje łączą się z bazą przez nazwę w DNS, którą da się przestawić na nowy serwer, a cały dzień, gdy adres starego serwera jest wpisany na każdej stacji, w każdej usłudze integracji i w każdym raporcie; nazwę wprowadza się więc przed nocą przełączenia, nie w jej trakcie. Spis obejmuje wszystkie instancje SQL Server, także bazy laboratorium i kadr, oraz loginy, zadania nocne i klucze szyfrowania, których kopia bazy nie przenosi. Odtworzenie bazy na nowym serwerze jest od razu testem kopii, a na kopii ludzie z oddziału i statystyki przechodzą ścieżkę pacjenta do eksportu do rozliczeń. Plan przełączenia ma godzinę decyzji i osobę, która ją podejmuje, bo kopii z nowszej wersji SQL Server nie da się odtworzyć na starszej, a stary serwer zostaje wyłączony, nie skasowany, do pierwszego rozliczenia z NFZ na nowej bazie (Migracja danych bez przestoju).

Zapis w spisie i analizie ryzyka

W podmiocie kluczowym i ważnym system zarządzania bezpieczeństwem obejmuje szacowanie ryzyka, zarządzanie aktywami i regularne aktualizacje stosownie do zaleceń producenta, z analizą ich wpływu na bezpieczeństwo usługi (art. 8 ust. 1 pkt 1, pkt 2 lit. m i pkt 5 lit. b ustawy o KSC), a przy łańcuchu dostaw uwzględnia się podatności związane z dostawcą oprogramowania (art. 8 ust. 2 pkt 1). Gdy producent nie wydaje już poprawek, zostaje udokumentowana decyzja: dlaczego sprzęt pracuje, jakie zabezpieczenia zastępcze działają, kto odpowiada i do kiedy zostanie wymieniony. Każdy taki komputer ma w spisie właściciela biznesowego, kierownika pracowni, a nie informatyka (Spis systemów z właścicielem). Przychodnię spoza ustawy o KSC obowiązują środki dobrane do ryzyka z uwzględnieniem stanu wiedzy technicznej (art. 32 ust. 1 RODO), a komputera w rejestracji bez poprawek od roku, z dostępem do danych i internetu, trudno bronić jako środka odpowiedniego do ryzyka.

Aktualizacje: okno serwisowe, test i plan wycofania

Nowa wersja zainstalowana w piątek po południu potrafi zamknąć lekarzowi program w połowie wpisu, a błąd, na przykład niedziałający wydruk e-skierowania, wychodzi w poniedziałek rano przy pierwszym pacjencie. Zwykle brakuje trzech rzeczy: uzgodnionego terminu, sprawdzenia kilku czynności i decyzji, co robicie, gdy coś nie działa.

Z aktualizacji zrezygnować nie można, bo zabezpieczenie dokumentacji wymaga dbałości o aktualizację oprogramowania (§ 1 ust. 5 pkt 4 rozporządzenia o dokumentacji medycznej), a nowe wersje przynoszą zmiany w P1, rozliczeniach z NFZ i słownikach. Ta sama placówka ma zapewnić wykorzystanie dokumentacji bez zbędnej zwłoki (§ 1 ust. 7). Dostawcę instalującego wersję zdalnie łączy z placówką zwykle umowa powierzenia, której realizacja nie może zakłócać udzielania świadczeń ani dostępu do danych z dokumentacji (art. 24 ust. 5 ustawy o prawach pacjenta), a instalacja odcinająca dostęp do kart w środku przyjęć jest takim zakłóceniem.

Okno serwisowe ustala placówka. Dobre okno wypada poza godzinami przyjęć, ma po sobie pełny dzień pracy serwisu dostawcy i zakłada, że rano ktoś sprawdzi podstawowe czynności. Piątek po południu tego nie spełnia, bo przy serwisie pracującym w dni robocze na naprawę błędu zostaje reszta jego dnia, a potem weekend. Lepiej sprawdza się wieczór we wtorek albo w środę, z testem następnego dnia przed pierwszym pacjentem. Do umowy trafia wyprzedzenie zapowiedzi, opis zmian zrozumiały dla rejestracji, długość przerwy, dozwolone dni i godziny i osoba, która zatwierdza termin, a osobno tryb poprawek bezpieczeństwa, których nie odkłada się do najbliższego okna (Czasy reakcji).

Test kilka dni przed i rano po. Przychodnia nie musi mieć serwera testowego; wystarczy nowa wersja udostępniona przez dostawcę kilka dni wcześniej, z danymi fikcyjnych pacjentów, bo kopia prawdziwej bazy na komputerze testowym to dane pacjentów chronione słabiej niż produkcja (Dane pacjentów poza produkcją). Test to codzienna ścieżka rejestratorki i lekarza: zapis na wizytę, wpis, e-recepta, e-skierowanie, wydruk, zlecenie do laboratorium i wynik, a przy kontrakcie z NFZ zestawienie do rozliczenia. Próbnej e-recepty w produkcji się nie wystawia, więc pierwszą e-receptę dnia lekarz wystawia prawdziwemu pacjentowi i sprawdza kod i wydruk, zanim wejdzie drugi. Rano każdy loguje się na swoim komputerze, bo drukarka recept, czytnik kart i podpis działają na konkretnym stanowisku, a ktoś sprawdza, czy pierwszy wynik z laboratorium dotarł do karty, bo nowa wersja potrafi zmienić format wymiany bez komunikatu.

Plan wycofania z decyzją przed pierwszym pacjentem. Kopia tuż przed instalacją, bo nocna nie obejmuje dnia wizyt. Godzina decyzji rano przed otwarciem rejestracji, bo wersja zmieniająca strukturę bazy nie daje się odinstalować, a wycofanie oznacza odtworzenie bazy i ponowne wprowadzenie wpisów; to, czy wersję da się wycofać i ile to trwa, placówka wie przed zgodą na termin. Decyduje kierownik placówki po rozmowie z serwisem, a nie technik, który ocenia własną wersję. Na ten czas rejestracja pracuje według kartki z rozdziału Praca bez systemu.

Chmura i Windows. W abonamencie terminu nie wybieracie, więc w regulaminie sprawdzacie godziny przerw, wyprzedzenie zapowiedzi, miejsce publikacji opisu zmian i to, kto wycofuje wadliwą wersję (Regulamin abonamentu); poranny test robi się tak samo. Na komputerach w rejestracji i gabinetach godziny aktywne obejmują czas przyjęć, a komputery zostają włączone na noc, gdy ma się zainstalować poprawka. Wyłączenie aktualizacji Windows nie jest rozwiązaniem, bo komputer bez poprawek jest łatwiejszym celem niż komputer, który raz w miesiącu restartuje się wieczorem.

Szpital. Okna bez pacjentów nie ma, więc wybiera się najmniejsze obciążenie, a oddziały dostają zapowiedź i kartkę pracy bez systemu. Szpital potrzebuje środowiska testowego z tymi samymi połączeniami co produkcja i kalendarza aktualizacji wszystkich systemów, żeby dwie zmiany nie wypadły tej samej nocy, a w szpitalu specjalistycznym test obejmuje połączenia z aparaturą i archiwum obrazowym. Podmiot kluczowy albo ważny zapewnia bezpieczeństwo utrzymania i eksploatacji systemu, w tym jego testowanie (art. 8 ust. 1 pkt 2 lit. b ustawy o KSC).

Certyfikaty TLS o coraz krótszej ważności

Wygasły certyfikat daje zwykle dwa objawy naraz: pacjent nie zapisze się przez stronę, bo przeglądarka ostrzega o niebezpiecznym połączeniu, a oddział nie dostaje wyników z laboratorium, bo ten sam certyfikat stał na serwerze integracji. Certyfikat działa do godziny zapisanej w nim co do sekundy. Zawodzi pamięć organizacji, gdy odnawiała go raz w roku jedna osoba.

Zasady publicznie zaufanych certyfikatów ustala CA/Browser Forum, porozumienie urzędów certyfikacji i producentów przeglądarek, które w kwietniu 2025 przyjęło uchwałę SC-081v3 (Baseline Requirements, sekcje 6.3.2 i 4.2.1, stan na 29.09.2026).

Ostatnie certyfikaty na 398 dni wygasają najpóźniej w połowie kwietnia 2027. Przy 200 dniach wymiana wypada mniej więcej co pół roku, przy 100 co kwartał, przy 47 osiem razy w roku albo częściej, a płatny certyfikat „na rok” oznacza kilka wydań i instalacji we wszystkich miejscach. Przy coraz krótszym ponownym użyciu niemal każde wydanie wymaga potwierdzenia, że domena jest wasza, a jeśli rekordami domeny zarządza firma, która kiedyś robiła stronę, to ona trzyma klucz do tego kroku.

Od certyfikatów zależą strona, zapisy online i portal pacjenta, poczta, także w telefonach personelu, brama VPN dla poradni, lekarzy i serwisu, a przede wszystkim połączenia bez przeglądarki: laboratorium, portal wyników, udostępnianie obrazów, silnik integracyjny, które po prostu przestają działać. Certyfikaty do P1 wydaje centrum certyfikacji Centrum e-Zdrowia, więc harmonogram CA/Browser Forum ich nie dotyczy; mają własny termin (instrukcja certyfikacji w P1 z 2018 roku podaje dwa lata), nowy generuje się przez wniosek w RPWDL, a po jego wystawieniu stary traci ważność. Gdy certyfikat P1 wygaśnie, lekarz zobaczy przy e-recepcie błąd, a nie przyczynę, więc jego data stoi w kalendarzu dwóch osób.

Spis. Dla każdego certyfikatu domena, wszystkie miejsca instalacji, wystawca, data wygaśnięcia, kto odnawia i jak. Zaczyna się od zewnątrz, od publicznych dzienników Certificate Transparency, w których musi być zarejestrowany każdy publiczny certyfikat, więc listę certyfikatów dla domen placówki odczytuje się bez dostępu do serwerów.

Automat. Wiele urzędów certyfikacji obsługuje protokół ACME (RFC 8555), w którym serwer sam prosi o certyfikat, potwierdza domenę i instaluje go. Urządzenie, które tego nie umie, wymienia się, dostaje certyfikat z wewnętrznego urzędu, staje za serwerem pośredniczącym albo ma opisaną procedurę ręczną z terminem. Automat potwierdzający domenę przez rekordy potrzebuje dostępu do strefy domeny albo wydzielonej poddomeny. Certyfikat wydany do 14 marca 2027 może mieć jeszcze 200 dni ważności, więc odnowienie przed tą datą daje jednorazowy zapas na wdrożenie automatu.

Niezależne sprawdzanie i umowy. Osobny mechanizm codziennie sprawdza daty od strony pacjenta i z wnętrza sieci i ostrzega wspólną skrzynkę działu; gdy do wygaśnięcia zostało mniej niż jedna trzecia ważności, automat nie zadziałał i ktoś reaguje tego samego dnia. Let's Encrypt od 4 czerwca 2025 nie wysyła przypomnień o wygasających certyfikatach. W umowach stoi, kto odpowiada za certyfikat na portalu pacjenta, kto ma dostęp do domeny, kto odnowi certyfikat w sobotę w nocy i czy wymiana jest w cenie utrzymania, bo płatna za każdym razem rośnie z każdym skróceniem ważności.

Przy odnawianiu psują się zwykle te same rzeczy: certyfikat wymieniony w jednym z trzech miejsc instalacji, brak certyfikatu pośredniego, certyfikat przypięty na stałe w aplikacji i usługa nieprzeładowana po wymianie. Przepis nie mówi, jak często odnawiać certyfikat, ale portal wyników wyłączony przez wygasły certyfikat to problem dostępności (art. 32 ust. 1 lit. b RODO), a w podmiocie kluczowym albo ważnym certyfikaty należą do polityk stosowania kryptografii i do zarządzania aktywami (art. 8 ust. 1 pkt 2 lit. k i m ustawy o KSC).

Urządzenia medyczne, których nie wolno aktualizować

W wielu pracowniach przy konsoli aparatu stoi komputer z systemem, dla którego producent od lat nie wydaje poprawek, z naklejką serwisu zakazującą instalowania czegokolwiek. Wysyła badania do archiwum, pobiera listę pacjentów, jest w tej samej sieci co rejestracja, a serwis łączy się z nim zdalnie, kiedy chce. Razem daje to najstarszy system w placówce z najszerszym dostępem do sieci. Tego aparatu nie załatacie. Możecie sprawić, że nikt obcy do niego nie dojdzie.

Tomograf czy aparat USG to wyrób medyczny według rozporządzenia (UE) 2017/745 (MDR), analizator to wyrób do diagnostyki in vitro według rozporządzenia (UE) 2017/746 (IVDR). Producent rozwija jego oprogramowanie z uwzględnieniem cyklu życia i zarządzania ryzykiem, w tym bezpieczeństwa informacji (załącznik I pkt 17.2 MDR, pkt 16.2 IVDR), a wyrób jest oceniony w konkretnej konfiguracji, którą poprawka albo antywirus zainstalowany przez placówkę zmienia. W zamian producent określa minimalne wymogi sprzętu, sieci i bezpieczeństwa informatycznego (pkt 17.4 MDR, pkt 16.4 IVDR) i podaje je w instrukcji używania (pkt 23.4 lit. ab MDR, pkt 20.4.1 lit. ah IVDR). Aparat certyfikowany według dawnych dyrektyw mógł przyjść bez takiego opisu, więc trzeba o niego poprosić, bo od niego zaczyna się projekt sieci. Obowiązki z aktu o cyberodporności tych wyrobów nie obejmują (Akt o cyberodporności).

Obowiązek aktualizacji z rozdziału o systemach bez wsparcia odwołuje się do zaleceń producenta (art. 8 ust. 1 pkt 5 lit. b ustawy o KSC). Gdy producent aparatu aktualizacji nie zaleca, ciężar przechodzi na szacowanie ryzyka, zarządzanie aktywami, monitorowanie w trybie ciągłym i czasowe ograniczenie ruchu po dostrzeżeniu podatności (art. 8 ust. 1 pkt 1, pkt 2 lit. m i g, pkt 5 lit. d).

Krok pierwszy: spis z działem aparatury. Dział aparatury ma ewidencję, dział IT listę adresów, a rzadko ktoś połączył jedno z drugim; w badaniu stopnia informatyzacji Centrum e-Zdrowia za 2025 rok z oprogramowania do ewidencji wyrobów medycznych korzystało 16,4% badanych szpitali. Przy każdym urządzeniu w sieci zapisuje się model, lokalizację i numer inwentarzowy, adres i system stacji sterującej, z czym się łączy, kto serwisuje i jak wchodzi zdalnie, czy producent dopuszcza poprawki, czy jest dokument z wymogami sieci i czy na urządzeniu zostają dane pacjentów. Adresy bierze się z serwera DHCP i tablic przełączników, a podsieci z aparaturą skanuje poza godzinami badań i najłagodniejszymi ustawieniami, bo stara stacja potrafi się zawiesić od agresywnego skanu. Te wiersze trafiają do tego samego spisu systemów, nie do osobnej tabeli działu aparatury.

Krok drugi: osobna sieć z regułami. Aparat rozmawia wyłącznie z tym, czego potrzebuje: tomograf z archiwum i listą pacjentów, analizator z systemem laboratoryjnym. Grupy urządzeń, na przykład pracownia obrazowa, laboratorium i monitory na oddziałach, dostają osobne segmenty, a między segmentem a resztą placówki stoi zapora z regułami dla konkretnych połączeń, bez dostępu do internetu i bez drogi z rejestracji. Port z aparatem jest na stałe przypisany do segmentu, wolne gniazda w pracowni wyłączone, a urządzenia bezprzewodowe mają własną sieć bezprzewodową. Serwis zdalny wchodzi jedną bramą placówki: konto imienne, uwierzytelnianie wieloskładnikowe (MFA), dostęp na czas pracy i zapis sesji, a stare tunele i programy do zdalnego pulpitu omijające bramę trzeba znaleźć i wyłączyć (Konta i dostęp serwisu). Reguły zmienia się poza godzinami badań, razem z kierownikiem pracowni, i kończy testem: badanie wykonane, obraz w archiwum, wynik w systemie. Odcięcie sprawdza się z samej stacji, próbą otwarcia strony i połączenia z serwerem spoza listy; jeśli się udało, segment istnieje tylko w dokumentacji.

Krok trzeci: monitorowanie z zewnątrz. Agenta na stacji tomografu nie zainstalujecie, więc monitorowanie w trybie ciągłym (art. 8 ust. 1 pkt 2 lit. g ustawy o KSC) prowadzi się z sieci: zapora zapisuje połączenia, a alarm pojawia się, gdy aparat łączy się z adresem spoza listy, w segmencie pojawia się nowe urządzenie albo ktoś spoza bramy próbuje dostać się do stacji. Plan na alarm mówi, który aparat można odciąć od razu, a którego nie rusza się w trakcie badania, i kto odtwarza stację po ataku.

Umowa serwisowa i zakupowa. Najtańszy moment na zmianę to zakup aparatu albo przedłużenie serwisu. Do umowy trafia: dokument z wymogami sieci przed instalacją; pełna lista połączeń aparatu i zgoda na pracę w segmencie za zaporą; informacja o podatnościach i o końcu wsparcia systemu stacji z wyprzedzeniem, z ofertą wymiany; tryb poprawek zatwierdzanych przez producenta; serwis zdalny tylko przez bramę placówki na konta imienne; powiadomienie o incydencie po stronie serwisu w czasie, który pozwoli dotrzymać terminów z rozdziału Dwa zegary; odtworzenie stacji po awarii z terminem; postępowanie z dyskiem stacji przy wymianie aparatu. Dostęp do danych generowanych przez aparat opisuję w rozdziale Dane z podłączonego aparatu.

Kto to utrzymuje: informatyk na etacie, firma czy model mieszany

W przychodni z początku jedyny klucz do szafy miał informatyk, który przyjeżdża we wtorki. W szpitalu ten sam kłopot wygląda inaczej: w dziale informatyki złożonym z dwóch osób wystarczy urlop jednej i zwolnienie drugiej, żeby drukarka opasek w izbie przyjęć i konto nowej pielęgniarki czekały tydzień, a firma informatyczna ma w umowie serwery i sieć, bez stanowisk. Po każdym z poprzednich rozdziałów zostaje pytanie, kto to zrobi i kto go zastąpi, a pytanie „etat czy firma” pada zwykle za wcześnie.

Najpierw spis zadań. Stanowiska i drukarki, konta i uprawnienia, serwery i kopie, sieć i łącza, kontakt z dostawcami, bezpieczeństwo i incydenty, zakupy, dokumentacja infrastruktury, a przy każdej pozycji trzy kolumny: kto wykonuje, kto zastępuje, kto decyduje, gdy trzeba wydać pieniądze albo zatrzymać system. Na liście brakuje zwykle osoby, która przyjmuje każde zgłoszenie, sprawdza je w pierwszych minutach i sama przekazuje dalej, żeby personel znał jeden numer.

Etat i firma. Informatyk na etacie zna placówkę i jest na miejscu, gdy staje rejestracja, ale ma urlop, choruje i odchodzi, a niespisana wiedza wychodzi razem z nim. Stałej gotowości jednej osoby nie da się też ułożyć wbrew 11 godzinom nieprzerwanego odpoczynku na dobę (art. 132 § 1 i art. 151⁵ § 2 Kodeksu pracy). Firma daje zastępstwo i specjalistów od sieci, baz i bezpieczeństwa, ale nie zna procesów, dopóki ich nie opiszecie, a umowa godzinowa płaci za usuwanie awarii, nie za zapobieganie. Z firmą z dostępem do danych zawiera się umowę powierzenia (art. 28 ust. 3 RODO), a odpowiedzialności nie da się przekazać: obowiązki z art. 32 RODO zostają przy placówce, a w podmiocie kluczowym albo ważnym kierownik odpowiada za obowiązki także wtedy, gdy powierzył je innej osobie (art. 8c ust. 1 i 3 ustawy o KSC). Porównuje się roczny koszt tego samego spisu zadań, z zastępstwem na urlop po stronie etatu i godzinami ponad pakiet po stronie firmy, a po roku liczbę zgłoszeń, czas ich zamknięcia i powtórzenia.

Model mieszany. Ludzie placówki trzymają klucze i decyzje, firma daje specjalistów i zastępstwo. W placówce zostaje osoba, która zna procesy, prowadzi spis zadań i systemów i zarządza kontami administratorów; firma dostaje monitoring bezpieczeństwa, konfigurację sieci, testy i wsparcie przy incydencie. Ustawa o KSC przewiduje realizację zadań przez wewnętrzne struktury lub przez umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa (art. 14), informacja o takiej umowie trafia do wykazu (art. 7 ust. 2 pkt 16), a jej zmianę zgłasza się w 14 dni (art. 7c ust. 3). Firmie nie oddaje się trzech rzeczy: kont administratorów, bo firma pracuje na kontach imiennych zakładanych i wyłączanych przez placówkę (Konta i dostęp serwisu), dokumentacji infrastruktury, którą firma uzupełnia, ale która leży w placówce, i decyzji o zatrzymaniu systemu.

Umowa z firmą. Kto przyjmuje zgłoszenie w nocy i w święto, jeśli placówka pracuje całą dobę; czas do rozpoczęcia pracy i do przywrócenia działania, osobno dla awarii zatrzymującej rejestrację i dla drobnej usterki; lista objętych stanowisk, urządzeń i systemów; imienny opiekun i jego zastępca. Na początek kilka tygodni, w których firma spisuje infrastrukturę, konta i kopie. Na koniec przekazanie dokumentacji, haseł i konfiguracji, które trzeba wpisać, bo samo z przepisu nie wynika, obok zwrotu albo usunięcia danych (art. 28 ust. 3 lit. g RODO).

Dokumentacja infrastruktury i urlop jako test

Dokumentacja nie powstanie po godzinach. Dyrektor daje na nią czas w grafiku i mówi wprost, po co jest: żeby informatyk mógł pojechać na urlop i nie odbierać telefonu. Podmiot kluczowy albo ważny prowadzi dokumentację bezpieczeństwa systemu, w tym charakterystykę infrastruktury, z oznaczaniem wersji (art. 10 ust. 1, ust. 3 i ust. 6 ustawy o KSC). Przywrócenie danych, które umie przeprowadzić jedna osoba, jest zdolnością tej osoby, a nie placówki, której wymaga art. 32 ust. 1 lit. c RODO.

Pierwszą stroną jest karta serwerowni z rozdziału Serwerownia. Reszta odpowiada na pytania, które zastępca zada o 7:40:

1. Schemat sieci z datą ostatniej zmiany, z łączem zapasowym.
2. Instrukcje krok po kroku: odnowienie certyfikatu P1, restart usług systemu, dodanie i blokada użytkownika, odtworzenie bazy z kopii, przełączenie łącza.
3. Dostęp: konta imienne, hasła w menedżerze haseł dostępnym dla co najmniej dwóch osób, dostęp awaryjny w zaklejonej kopercie w sejfie dyrektora, z nowym hasłem po każdym otwarciu.
4. Kalendarz terminów: certyfikaty, licencje, domeny, koniec wsparcia, koniec umów, w kalendarzu dwóch osób.
5. Kontakty i numery umów każdego dostawcy, z godzinami serwisu i nazwiskami osób, od których przyjmie zgłoszenie.
6. Czynności ręczne robione co tydzień albo co miesiąc, na przykład skrypt przed zamknięciem miesiąca w rozliczeniach.
7. Konta u dostawców (domena, licencje, zapora) przepisane z prywatnego adresu informatyka na adres służbowy dostępny dla więcej niż jednej osoby.

Instrukcję najlepiej pisze osoba, która robi czynność pierwszy raz pod okiem autora, a zmiana w infrastrukturze jest skończona, gdy dokumentacja ma nową wersję. Jedna aktualna kopia leży poza siecią, wydrukowana w sejfie albo na zaszyfrowanym nośniku, bo przy ataku szyfrującym plik na serwerze przepada razem z serwerem.

Gdy urlop jest dzielony na części, co najmniej jedna powinna trwać nie mniej niż 14 kolejnych dni kalendarzowych (art. 162 Kodeksu pracy), więc dwa tygodnie to gotowy test. Zastępca pracuje wyłącznie z dokumentacji, każdy telefon do urlopowicza trafia na listę z datą i brakującą informacją, a po powrocie informatyk uzupełnia dokumentację. Raz w roku zastępca albo firma wykonuje najtrudniejszą instrukcję sam, łącznie z odtworzeniem bazy, a dyrektor raz na kwartał dostaje jedną liczbę: ile czynności krytycznych ma tylko jednego wykonawcę. Plan przekazania przed emeryturą zaczyna się rok wcześniej, a każde odejście kończy się protokołem przekazania. Konto osoby, która odchodzi, razem z VPN i zdalnym pulpitem wyłącza się w ciągu doby, a najlepiej wygasa samo z datą końca umowy wpisaną przy zakładaniu; hasła do kont wspólnych, które znała, zmienia się przy każdym odejściu.

Co to znaczy na waszej skali

Pytania są te same od gabinetu do sieci szpitali: gdzie działa system, kto wie o awarii, gdzie leży kopia i kto ją ostatnio odtworzył. Jak z każdym krokiem wzrostu przybywa warstw IT, opisuję w tekście Kwestia skali. Placówka prowadzona przez mikro albo małego przedsiębiorcę co do zasady jest poza ustawą o KSC (art. 5 ust. 1 pkt 1 i ust. 2 pkt 1), a podmiot leczniczy niebędący przedsiębiorcą, na przykład SPZOZ, jest podmiotem ważnym od 50 zatrudnionych i kluczowym od 250 (art. 5 ust. 8); szczegóły w rozdziale Czy ustawa was obejmuje.

Gabinet lekarski

Program w abonamencie z umową powierzenia, pisemną odpowiedzią dostawcy, kiedy ostatnio odtworzył bazę, i próbnym eksportem raz w roku na zaszyfrowany dysk w zamkniętym miejscu. Aktualny laptop z godzinami aktywnymi na czas przyjęć i reguła „żadnych instalacji w godzinach przyjęć”. Zapasowe łącze to internet w telefonie, a w szufladzie leży grafik na następny dzień. Jeśli program stoi na komputerze w gabinecie, kopia trafia poza gabinet razem z instalatorem i kluczem licencji, hasło do dysku leży w kopercie w innym miejscu, a test to otwarcie pięciu kart na drugim komputerze po przyjęciach. W kalendarzu data certyfikatu P1, a domena gabinetu zarejestrowana na gabinet. Serwerowni, schematu sieci i środowiska testowego gabinet nie potrzebuje.

Przychodnia

Decyduje pytanie, czy jest ktoś, kto utrzyma serwer, i czy ma zastępcę. Jeśli nie, SaaS z routerem z kartą SIM innej sieci, sprawdzanym raz w miesiącu, i spisem urządzeń przed umową. Przy własnym serwerze pełne minimum: zamknięta szafa z listą osób z kluczem, UPS dla serwera, przełącznika i routera z automatycznym wyłączeniem, powiadomienia do dwóch osób, kopia poza budynkiem, test z protokołem i karta serwerowni. Okno serwisowe w umowie i test na jednej kartce. Spis komputerów w tydzień, osobna sieć dla stacji przy aparatach, tabela certyfikatów. Podłogi technicznej, gaszenia gazem, agregatu ani drugiej serwerowni przychodnia nie potrzebuje.

Sieć przychodni

Jedna baza pacjentów, więc SaaS albo chmura prywatna, bo serwer w każdej przychodni to osobna kartoteka tego samego pacjenta (Jedna baza pacjentów). Decyzje o kopiach, oknach aktualizacji i uprawnieniach zapadają w zarządzie. Pełne minimum serwerowni w jednej lokalizacji z serwerem, w pozostałych szafka z routerem i przełącznikiem na UPS, a łącze każdej lokalizacji z zapasem, bo jego awaria odcina ją od wspólnej bazy. Test kopii obejmuje centralną bazę raz, a w lokalizacjach to, co przechowują u siebie. Jedna polityka kopii, jeden wzór spisu, jedna brama serwisu, jedna umowa z firmą i karta lokalizacji z osobą na miejscu, która według instrukcji zrestartuje router. Status w ustawie o KSC liczy się dla całego podmiotu.

Szpital

Serwer lokalny albo chmura prywatna z kopią w innej lokalizacji i co kwartał test innego systemu krytycznego. Droga od łóżka do serwera dla każdego oddziału, UPS w szafach na piętrach, pomiar Wi-Fi na trasie obchodu, segmentacja oddzielająca gości, administrację i aparaturę od stanowisk klinicznych, drugie łącze inną drogą fizyczną. Środowisko testowe, kalendarz aktualizacji i decyzja dyrektora o płatniku migracji serwera bazy. Segmentację aparatury zaczyna się od pracowni obrazowej i laboratorium, a dyżur poza godzinami działu IT opisuje umowa z firmą z imiennymi osobami. Terminy z ustawy o KSC są w rozdziale Kalendarz.

Szpital specjalistyczny

Dziesiątki typów aparatów, więc każdy nowy aparat przechodzi przez IT przed instalacją, segmenty dzieli się według grup urządzeń i producentów, a alarmy z nich odbiera funkcja bezpieczeństwa. Kopię do testu wskazuje zespół bezpieczeństwa, a archiwum obrazowe ma osobny pomiar czasu przeniesienia. Serwery, których nie przeniesiono przed końcem wsparcia, stoją w osobnym segmencie.

Sieć szpitali

Wspólne standardy: jedno minimum serwerowni, sieci, zasilania i Wi-Fi, jeden wzór segmentów aparatury i wymagań w zakupach, jedna wersja docelowa bazy i systemu, jedna brama serwisu zdalnego, spis certyfikatów i automat ze wspólnym zarządzaniem domenami. Pomiary i testy robi się w każdym szpitalu osobno: systemy wspólne odtwarza się raz, system szpitalny każdego szpitala ma własny test. Przy wspólnym systemie łącze między szpitalami jest częścią systemu każdego z nich i ma zapasową drogę. Podział zadań między centralę i szpitale opisuję w rozdziale Wspólny zespół bezpieczeństwa.

Typowe błędy

Kopia w tym samym pomieszczeniu co system. Dysk w tej samej szafie albo udział w tej samej sieci; pożar, zalanie i atak zabierają bazę i kopię naraz.

Kopia nigdy nieodtworzona. Zielony raport uznany za dowód, test na tym samym serwerze, sukces ogłoszony przez informatyka bez pięciu kart otwartych przez personel, kopia w chmurze bez protokołu dostawcy.

Płaska sieć dla aparatów i biura. Aparatura, kamery, goście i administracja razem ze stanowiskami klinicznymi albo segment na schemacie, przez który zapora przepuszcza wszystko.

Zasilanie i łącze bez próby. UPS tylko dla serwera, klimatyzator na wspólnym wyłączniku, szafy na piętrach bez zasilania awaryjnego, drugie łącze od tego samego operatora tym samym kanałem.

ESU zamiast planu. Licencja bez aktywacji, rok ESU bez daty wyjścia, spis tylko komputerów w domenie, migracja serwera bazy w miejscu bez drogi powrotu.

Certyfikat odnawiany ręcznie przez jedną osobę. Przypomnienie na skrzynkę osoby, która odeszła, domena zarejestrowana na firmę od strony, certyfikat P1 bez daty w kalendarzu.

Aktualizacja w piątek bez planu wycofania. Instalacja „kiedy będzie gotowa”, test sprawdzający tylko uruchomienie, brak kopii tuż przed instalacją i decyzja o wycofaniu odkładana do południa. Po drugiej stronie odkładanie aktualizacji miesiącami, bo poprzednia coś zepsuła.

Wiedza w jednej głowie. Dokumentacja na serwerze, który opisuje, napisana raz przed kontrolą i sprawdzona tylko przez autora, hasła w zeszycie, wiedza przeniesiona do firmy zamiast do placówki, wspólne konto administratora całej firmy.

Od czego zacząć w tym tygodniu

1. Zapiszcie, kto i kiedy ostatni raz odtworzył system z kopii; jeśli nikt, wyznaczcie system i datę testu, a w chmurze poproście dostawcę o test na osobnej instancji.
2. Sprawdźcie, gdzie fizycznie leży kopia, i jeśli w tej samej szafie albo sieci co serwer, zaplanujcie kopię poza budynkiem i drugą odłączoną od sieci.
3. Ustawcie powiadomienia o temperaturze, dyskach i pracy UPS na baterii do dwóch osób i wyślijcie próbne.
4. Zróbcie obchód po komputerach z Windows 10, stacjach przy aparatach i serwerach z SQL Server 2016 albo Windows Server 2016, każdy z decyzją, osobą i terminem.
5. Spiszcie certyfikaty z datami ważności, razem z certyfikatem P1, w kalendarzu dwóch osób.
6. Przełączcie łącze na zapasowe w uzgodnionym oknie i zapiszcie, czy rejestracja pracowała dalej.
7. Zapytajcie każdego informatyka, czego nie mógłby jutro przekazać komuś innemu, i przy każdej odpowiedzi wpiszcie instrukcję, termin i osobę przejmującą.

Przebieg testu z punktu pierwszego zapiszecie w Protokole testu odtworzenia kopii, godzina po godzinie.

Ile godzin trwałoby u was odtworzenie systemu, od którego zależy przyjęcie pacjenta, i kto w placówce zna dziś tę liczbę z testu, a nie z przypuszczenia?