Dlaczego w ogóle trzymać dokumentację medyczną w chmurze?
Najważniejsze korzyści z przeniesienia dokumentacji medycznej do chmury
Bezpieczne przechowywanie dokumentacji medycznej w chmurze to nie fanaberia działu IT, tylko realne narzędzie do zapewnienia ciągłości pracy placówki. Tradycyjny model: pojedynczy serwer w piwnicy, kilka komputerów w sieci lokalnej i kopia „na pendrivie” coraz częściej kończy się awarią, przestojem lub realnym incydentem bezpieczeństwa. Chmura umożliwia podzielenie odpowiedzialności: placówka skupia się na procesie, a dostawca chmury na infrastrukturze, redundancji i bezpieczeństwie fizycznym.
Największa praktyczna korzyść to dostępność danych. Lekarz może zalogować się do systemu EDM z dowolnego gabinetu, z innej lokalizacji, a nawet z bezpiecznego urządzenia poza placówką. Wyniki badań, opisy hospitalizacji, dokumentacja zdjęciowa – wszystko dostępne w jednym miejscu, bez przerzucania pendrive’ów czy wysyłania plików mailem. To bezpośrednio wpływa na jakość opieki i szybkość reakcji.
Drugi filar to mniejsze koszty utrzymania infrastruktury. Zakup i wymiana serwerów, macierzy dyskowych, licencji, zasilania awaryjnego, klimatyzacji serwerowni – to wydatki, które w modelu chmurowym częściowo lub całkowicie przechodzą na stronę usługodawcy. Zamiast dużej inwestycji na start pojawia się przewidywalna opłata abonamentowa, zwykle skalowana do liczby użytkowników lub wolumenu danych.
Trzecia korzyść to ciągłość działania. Profesjonalne centra danych mają redundancję zasilania, łącza internetowe od wielu operatorów, systemy przeciwpożarowe, monitoring i procedury odtwarzania po awarii. Samodzielne odtworzenie podobnego poziomu odporności na incydenty przez pojedynczą przychodnię jest praktycznie niewykonalne – zarówno finansowo, jak i organizacyjnie.
Przykładowe scenariusze użycia chmury w różnych typach placówek
W małym gabinecie lekarskim chmura bywa jedynym rozsądnym wyborem. Zwykle nie ma tam dedykowanego informatyka ani miejsca na pełnoprawną serwerownię. System EDM w modelu SaaS, działający w chmurze, rozwiązuje wiele problemów: aktualizacje oprogramowania, kopie zapasowe, bezpieczeństwo systemu operacyjnego. Lekarz i pielęgniarka logują się do aplikacji przez przeglądarkę lub dedykowany program – cała „magia” dzieje się po stronie dostawcy.
W sieci przychodni scenariusz jest inny. Często pojawia się potrzeba integracji danych z wielu lokalizacji, centrum call center, rejestracji online, teleporad, a także centralnej hurtowni danych. Chmura umożliwia zbudowanie jednej, spójnej platformy, do której łączą się wszystkie oddziały. Na tej bazie można realizować zaawansowane scenariusze: np. automatyczne kierowanie pacjenta do wolnego specjalisty w innej placówce, zachowując pełen wgląd w historię choroby.
Telemedycyna bez chmury w praktyce nie działa. Zdalne pomiary, konsultacje wideo, przesyłanie wyników badań z domu pacjenta, aplikacje mobilne – wszystkie te elementy naturalnie opierają się na usługach chmurowych. Dane spływają z dziesiątek, setek, a w większych projektach tysięcy urządzeń. Próba utrzymania tego wyłącznie na jednym lokalnym serwerze szybko kończy się niewydolnością systemu i kłopotami z bezpieczeństwem.
Mit: chmura jest z natury mniej bezpieczna niż „serwer w piwnicy”
Często powtarzane zdanie: „Nie przenosimy dokumentacji medycznej do chmury, bo to niebezpieczne” zwykle oznacza jedno – brak świadomości realnych zagrożeń w aktualnym środowisku. Serwer stojący obok rejestracji, bez kontroli dostępu fizycznego, z przestarzałym systemem operacyjnym, backupem na tym samym dysku i administrowany „po godzinach” przez znajomego informatyka bywa w rzeczywistości znacznie mniej bezpieczny niż dobrze skonfigurowana usługa chmurowa.
Rzeczywiste ryzyka dla dokumentacji medycznej to między innymi: brak łatek bezpieczeństwa, brak monitoringu, pojedynczy punkt awarii, proste hasła, brak szyfrowania dysków, brak procedur reakcji na incydenty. Profesjonalny dostawca chmury utrzymuje zespoły bezpieczeństwa, systemy wykrywania włamań, centralne zarządzanie aktualizacjami, dzienniki zdarzeń i mechanizmy szyfrowania na poziomie infrastruktury.
Mit, że „jak dane są u mnie w szafie, to są bezpieczniejsze”, wynika z iluzji kontroli. Jest widoczny serwer, można go dotknąć, więc wydaje się, że nad wszystkim jest pełna panika nadzór. Tymczasem bezpieczeństwo to procedury, konfiguracja i kompetencje, a nie fizyczna bliskość urządzenia. Chmura nie jest automatycznie bezpieczna – ale poprawnie wybrany i skonfigurowany dostawca najczęściej zapewni wyższy poziom ochrony, niż większość lokalnych serwerowni w małych i średnich placówkach.
Ryzyka związane z brakiem chmury i trwaniem przy „lokalnych” rozwiązaniach
Brak chmury nie oznacza braku ryzyka, wręcz przeciwnie. Jedno urządzenie przechowujące całą dokumentację medyczną to klasyczny pojedynczy punkt awarii. Awaria dysku, uszkodzenie zasilacza, zalanie, pożar – w takim scenariuszu często tracona jest nie tylko dostępność systemu, ale również część danych, jeśli kopia zapasowa nie była wykonywana i testowana regularnie.
Kolejny problem to kradzież lub zagubienie sprzętu. Laptop z lokalną bazą danych, tablet z kopiami plików, dysk zewnętrzny z backupem trzymany w szufladzie – to proste cele dla złodziei. Jeśli dane nie są szyfrowane i nie ma możliwości zdalnego wyczyszczenia urządzenia, incydent przeradza się w poważne naruszenie bezpieczeństwa danych osobowych.
Trzecie ryzyko: brak skalowalności i aktualizacji. System zainstalowany kilka lat temu, nietknięty aktualizacjami, działający na niewspieranym już systemie operacyjnym, jest idealnym celem dla złośliwego oprogramowania, w tym ransomware. Chmura, przy odpowiednio dobranym modelu, pozwala szybciej aktualizować oprogramowanie i infrastrukturę, bo robi to zespół, dla którego jest to podstawowa działalność.
Kiedy chmura ma sens, a kiedy lepiej rozważyć model hybrydowy
Są sytuacje, w których pełne przeniesienie dokumentacji medycznej do chmury nie jest od razu optymalnym ruchem. W dużych szpitalach z rozbudowaną infrastrukturą i systemami działającymi od wielu lat rozsądnym etapem przejściowym bywa model hybrydowy. Część danych (np. archiwalne obrazy, kopie zapasowe, dane z telemedycyny) ląduje w chmurze, natomiast główny system HIS/EDM działa jeszcze w lokalnym centrum danych.
Model hybrydowy ma sens także wtedy, gdy pojawiają się specyficzne wymagania co do opóźnień (np. systemy czasu rzeczywistego, integracja ze sprzętem medycznym) albo gdy obecna licencja na system lokalny kończy się za parę lat i ekonomicznie rozsądniej jest wykorzystać ją do końca, jednocześnie już dziś budując elementy chmurowe wokół.
Natomiast w gabinetach, małych przychodniach czy startujących podmiotach telemedycznych pełna chmura jest zwykle najbezpieczniejszą i najbardziej opłacalną ścieżką. Budowanie własnej serwerowni pod niewielką liczbę stanowisk generuje koszty i ryzyka nieproporcjonalne do skali działalności.
Podstawy prawne i odpowiedzialność za dane medyczne
Dane medyczne jako szczególna kategoria danych osobowych
Dokumentacja medyczna to nie są „zwykłe” dane osobowe. Zgodnie z RODO to szczególna kategoria danych, której przetwarzanie podlega zaostrzonym zasadom. Oprócz RODO zastosowanie mają między innymi przepisy o prawach pacjenta i dokumentacji medycznej, krajowe przepisy o systemie informacji w ochronie zdrowia, rozporządzenia dotyczące dokumentacji medycznej oraz ewentualne wymogi sektorowe.
Zakres informacji gromadzonych w dokumentacji medycznej – rozpoznania, wyniki badań, opisy zabiegów, informacje o lekach, czasami dane wrażliwe dotyczące np. zdrowia psychicznego czy chorób przewlekłych – sprawia, że potencjalny wyciek jest wyjątkowo dotkliwy. Dlatego prawo wymaga nie tylko zachowania poufności, lecz także zapewnienia integralności (brak nieuprawnionych zmian) i dostępności (dane muszą być dostępne, gdy są potrzebne do leczenia).
Kto jest administratorem danych i co to oznacza w praktyce
Administrator danych medycznych to najczęściej podmiot prowadzący działalność leczniczą: przychodnia, szpital, indywidualna praktyka lekarska, grupa praktyków. Administrator decyduje o celach i sposobach przetwarzania, co w praktyce oznacza odpowiedzialność za to, jak wybrany jest system, dostawca chmury, procedury wewnętrzne i poziom zabezpieczeń.
Mit, z którym dobrze się rozprawić: „Jak podpiszę umowę z dostawcą chmury, to on odpowiada za bezpieczeństwo”. Rzeczywistość jest inna – dostawca odpowiada w granicach umowy powierzenia i swoich zobowiązań kontraktowych, natomiast wobec pacjentów i organów nadzorczych pełna odpowiedzialność za legalność i bezpieczeństwo przetwarzania spoczywa na administratorze. To administrator wybiera dostawcę, nadzoruje go i powinien mieć możliwość wykazania, że zrobił to z należytą starannością.
Administrator musi wykazać, że spełnił zasady: legalności, minimalizacji danych, ograniczenia celu, rozliczalności. W praktyce oznacza to m.in. prowadzenie rejestru czynności przetwarzania, posiadanie polityk bezpieczeństwa, szacowanie ryzyka i podejmowanie adekwatnych środków technicznych i organizacyjnych. Chmura nie zwalnia z tych obowiązków – jest po prostu narzędziem, które trzeba dobrać i skonfigurować zgodnie z tymi zasadami.
Rola podmiotów przetwarzających: dostawca chmury, firma IT, dostawca EDM
Obok administratora pojawia się podmiot przetwarzający – czyli każdy, kto przetwarza dane osobowe w imieniu administratora. W kontekście dokumentacji medycznej w chmurze zwykle występuje kilka takich podmiotów:
dostawca systemu EDM lub HIS (oprogramowanie medyczne),
dostawca infrastruktury chmurowej (np. operator centrum danych),
firma IT administrująca systemami,
czasem dodatkowi podwykonawcy (np. dostawca usług backupu, archiwizacji, telekomunikacji).
Każdy z nich powinien mieć precyzyjnie określoną rolę w umowie powierzenia. Zakres przetwarzania, rodzaje danych, cele, czas trwania – wszystko to musi być opisane w sposób jednoznaczny. Dodatkowo administrator powinien wiedzieć, czy podmiot przetwarzający korzysta z podpowierzenia, czyli dalszych podwykonawców, i mieć możliwość ich zatwierdzenia lub sprzeciwu.
Z punktu widzenia praktyki ważna jest transparentność. Jeżeli dostawca systemu EDM hostuje rozwiązanie w infrastrukturze innego dostawcy chmury, administrator powinien o tym wiedzieć, znać lokalizację centrów danych oraz mieć zapewnienie, że wszyscy zaangażowani podwykonawcy spełniają odpowiednie standardy bezpieczeństwa i wymogi prawne.
Wymogi dotyczące lokalizacji danych i przechowywania dokumentacji medycznej
Dokumentacja medyczna podlega restrykcyjnym zasadom przechowywania. Przepisy krajowe określają minimalne okresy przechowywania poszczególnych typów dokumentów (np. przez kilkanaście czy kilkadziesiąt lat). Co ważne, dane nie mogą zostać „po prostu usunięte”, gdy półka się zapełni – system musi umożliwiać przechowywanie przez wymagany okres, a usuwanie dopiero po jego upływie i w sposób udokumentowany.
Dodatkowo pojawia się kwestia lokalizacji danych. RODO dopuszcza przetwarzanie danych w państwach UE/EOG oraz w państwach trzecich zapewniających odpowiedni poziom ochrony (np. na podstawie decyzji stwierdzającej odpowiedni stopień ochrony lub innych zabezpieczeń, takich jak standardowe klauzule umowne). W praktyce wielu administratorów w sektorze medycznym decyduje się na rozwiązania, w których dane pozostają fizycznie na terenie UE, co upraszcza wymogi prawne i zmniejsza ryzyko.
System przechowujący dokumentację medyczną w chmurze powinien zapewniać nie tylko przechowywanie, ale też niezmienność i integralność danych. Modyfikacje muszą być rejestrowane (logi), a architektura powinna utrudniać ich nieautoryzowane nadpisanie lub usunięcie. W razie sporu czy kontroli możliwe jest wówczas wykazanie historii zmian, dat dostępu, osoby dokonującej wpisu i jego modyfikacji.
Źródło: Pexels | Autor: Polina Tankilevitch
Jak ocenić, czy Twoja organizacja jest gotowa na chmurę
Fotografia stanu obecnego: gdzie faktycznie leżą dane
Zanim zacznie się dyskutować o wyborze dostawcy chmury, trzeba nazwać po imieniu punkt startu. W wielu placówkach dokumentacja medyczna funkcjonuje równolegle w kilku modelach:
papierowe teczki i księgi główne,
lokalne systemy EDM na jednym lub kilku serwerach,
skany przechowywane na współdzielonych dyskach sieciowych,
kopie na pendrive’ach i dyskach zewnętrznych,
pliki wysyłane mailem między lekarzami lub do zewnętrznych laboratoriów.
Analiza ryzyka: od zdrowego rozsądku do formalnego dokumentu
Przygotowanie do chmury nie zaczyna się od katalogu usług dostawcy, lecz od rzetelnej analizy ryzyka. Formalnie wymaga tego RODO, a praktycznie – bez tego łatwo przepalić budżet na zabezpieczenia, które nie rozwiązują realnych problemów.
Na początku przydaje się prosta mapa: co może pójść nie tak, z jakimi konsekwencjami dla pacjenta i dla placówki. Dla dokumentacji medycznej typowe scenariusze to:
brak dostępu do systemu (awaria, atak, katastrofa fizyczna),
nieuprawniony dostęp (atak z zewnątrz, błąd personelu, kradzież konta),
nieautoryzowana modyfikacja dokumentacji (błąd, sabotaż, brak kontroli wersji),
trwała utrata danych (brak działającego backupu, błędna konfiguracja replikacji).
Mit: „Jak wejdziemy w chmurę dużego dostawcy, to ryzyko przestaje istnieć”. Rzeczywistość: część ryzyk zmienia charakter, część się zmniejsza, ale dochodzą nowe – np. błędna konfiguracja usług, zbyt szerokie uprawnienia, brak kontroli nad kluczami szyfrującymi.
Analiza ryzyka powinna skutkować prostymi wnioskami operacyjnymi: które funkcje muszą działać zawsze, jaki maksymalny czas niedostępności jest akceptowalny, które dane są krytyczne i wymagają mocniejszych zabezpieczeń, a gdzie można dobrać rozwiązanie bardziej ekonomiczne.
Doświadczenie organizacji: procesy, nawyki i „szara strefa IT”
Technologia to połowa sukcesu. Druga połowa to nawyki ludzi i jakość procesów. Jeżeli w placówce funkcjonuje tzw. szara strefa IT – prywatne pendrive’y, prywatne konta w chmurze, wysyłanie dokumentacji przez prywatne maile – to nie jest problem „złych pracowników”, tylko sygnał, że oficjalne narzędzia są niewygodne lub niedostosowane.
Zanim zapadnie decyzja o migracji, warto przeanalizować:
jak personel faktycznie przesyła wyniki, zdjęcia, opisy badań,
czy logowanie do obecnych systemów jest szybkie i bezpieczne (np. SSO, karty, tokeny),
jak wygląda proces nadawania i odbierania uprawnień (nowy pracownik, odejście z pracy),
kto w praktyce „ratuje” system, gdy coś nie działa (wewnętrzne IT, zewnętrzna firma, „pan od drukarek”).
Jeśli na te pytania nie ma jasnych odpowiedzi, pełna migracja do chmury będzie ryzykowna. Najpierw trzeba poukładać procesy – choćby prostą procedurę nadawania uprawnień i listę osób odpowiedzialnych za decyzje.
Kompetencje zespołu: kto będzie „właścicielem” chmury
Każda chmura – nawet „w pełni zarządzana” – wymaga kogoś po stronie placówki, kto rozumie, o co pytać dostawcę i potrafi przeczytać logi czy raporty bezpieczeństwa. Nie musi to być architekt chmurowy z certyfikatami, ale ktoś, kto:
zna podstawowe pojęcia (backup, szyfrowanie, uprawnienia, logowanie dwuskładnikowe),
rozumie model odpowiedzialności dzielonej z dostawcą,
ma mandat, by wymagać zmian w konfiguracji i procedurach.
Mit: „Całe IT oddamy firmie zewnętrznej, my się nie musimy znać”. Rzeczywistość: odpowiedzialność prawna zostaje w placówce. Zewnętrzny partner może wykonać 90% pracy, ale administratorem danych pozostaje podmiot medyczny. Bez choćby podstawowego nadzoru merytorycznego łatwo podpisać umowę, która wygląda dobrze marketingowo, a rozjeżdża się z praktyką.
Plan dojścia: małe kroki zamiast rewolucji
Pełna migracja EDM do chmury nie musi być pierwszym krokiem. Bezpieczniej bywa zacząć od komponentów o niższym ryzyku operacyjnym, np.:
kopii zapasowych wybranych systemów,
archiwum badań obrazowych,
usług komunikacji z pacjentem (rejestracja online, powiadomienia SMS/e-mail),
systemu kolejkowego lub modułów raportowych.
Taki etap przejściowy pozwala przetestować współpracę z dostawcą, procedury zgłaszania incydentów, działanie wsparcia oraz faktyczną wydajność łączy. W razie problemów łatwiej też się wycofać lub zmienić konfigurację, niż w przypadku kluczowego systemu EDM.
Wybór modelu chmury i architektury: praktyczne warianty
Modele usług: IaaS, PaaS, SaaS w ochronie zdrowia
W uproszczeniu mamy trzy główne modele usług chmurowych:
IaaS (Infrastructure as a Service) – dostawca udostępnia infrastrukturę (maszyny wirtualne, dyski, sieć), a za systemy operacyjne, bazy danych, aplikacje i ich konfigurację odpowiada administrator lub jego partner IT.
PaaS (Platform as a Service) – dostawca udostępnia platformę (np. bazy danych, serwisy aplikacyjne), administrator zarządza własnymi aplikacjami na tej platformie.
SaaS (Software as a Service) – administrator korzysta z gotowej aplikacji (np. system EDM w modelu chmurowym), za infrastrukturę i większość warstw bezpieczeństwa odpowiada dostawca rozwiązania.
W małych i średnich placówkach medycznych najczęściej sprawdza się SaaS – gotowy system EDM od producenta, który przejmuje odpowiedzialność za aktualizacje, kopie zapasowe i większość konfiguracji bezpieczeństwa. IaaS i PaaS mają sens tam, gdzie buduje się własne rozwiązania, integracje lub platformy szpitalne łączące wiele systemów.
Chmura publiczna, prywatna i hybrydowa: co naprawdę oznaczają
W praktyce definicje marketingowe często wprowadzają w błąd. Chmura publiczna nie oznacza, że dane są „dostępne publicznie” – chodzi o model, w którym infrastruktura jest współdzielona między wielu klientów, ale z logiczną separacją zasobów (np. duzi globalni dostawcy). Chmura prywatna to dedykowana infrastruktura dla jednego klienta, często w centrum danych dostawcy lub we własnym data center.
Mit: „Dla danych medycznych dozwolona jest tylko chmura prywatna”. Rzeczywistość: przepisy nie zakazują chmury publicznej, wymagają natomiast zachowania odpowiedniego poziomu bezpieczeństwa i kontroli. Dobrze skonfigurowana chmura publiczna u renomowanego dostawcy często będzie bezpieczniejsza niż źle utrzymana „prywatna” serwerownia w piwnicy.
Model hybrydowy staje się naturalnym wyborem w dużych organizacjach: część systemów pozostaje lokalnie (sprzęt medyczny, systemy czasu rzeczywistego), natomiast moduły EDM, archiwizacja, analityka czy komunikacja z pacjentem działają w chmurze.
Segmentacja i mikrosegmentacja: ograniczanie skutków incydentu
Nawet najlepszy system można zneutralizować jednym błędem konfiguracyjnym. Dlatego architektura chmurowa dla danych medycznych powinna zakładać segmentację – oddzielanie od siebie różnych części systemu, tak aby naruszenie jednego elementu nie dawało automatycznie pełnego dostępu do wszystkiego.
Przykładowo:
moduły frontowe (portale, serwisy API) są odizolowane od baz danych z dokumentacją,
dostęp administracyjny do środowiska produkcyjnego jest możliwy wyłącznie z wybranych adresów lub przez bezpieczne połączenia VPN/Jumphost,
dane testowe nie zawierają realnej dokumentacji medycznej lub są solidnie zanonimizowane.
Mikrosegmentacja (np. oddzielne strefy sieciowe dla poszczególnych usług, restrykcyjne reguły firewalli) pozwala ograniczyć zasięg ataku, nawet gdy napastnikowi uda się przejąć pojedyncze konto czy usługę.
Szyfrowanie end-to-end i zarządzanie kluczami
Szyfrowanie danych „w spoczynku” i „w tranzycie” to obecnie standard, ale szczególnie w ochronie zdrowia znaczenie ma także zarządzanie kluczami szyfrującymi. Pojawia się pytanie: kto faktycznie kontroluje klucze – dostawca chmury czy administrator danych?
Bezpieczne warianty to m.in.:
korzystanie z usług zarządzania kluczami (KMS) z silnymi politykami kontroli dostępu,
rozwiązania, w których administrator ma własne, niezależne klucze (Customer Managed Keys),
oddzielenie zespołu, który zarządza kluczami, od zespołu, który administruje aplikacją.
Mit: „Jak dane są w chmurze zaszyfrowane, to temat jest zamknięty”. Rzeczywistość: równie ważne jak samo szyfrowanie jest to, kto może odszyfrować dane i w jakich okolicznościach. Bez dobrze zdefiniowanych ról i procedur łatwo o sytuację, w której teoretycznie bezpieczny system pozwala zbyt wielu osobom na zbyt szeroki dostęp.
Kryteria wyboru dostawcy chmury dla danych medycznych
Certyfikaty i standardy bezpieczeństwa – co ma znaczenie, a co jest marketingiem
Certyfikaty nie gwarantują absolutnego bezpieczeństwa, ale są dobrym filtrem przy wyborze dostawcy. W obszarze dokumentacji medycznej przydają się przede wszystkim:
ISO/IEC 27001 – system zarządzania bezpieczeństwem informacji,
ISO 27017 / 27018 – rozszerzenia dotyczące usług chmurowych i ochrony danych osobowych,
certyfikacje krajowe lub branżowe (np. wymogi dla dostawców usług dla sektora publicznego, e-zdrowia).
Sam certyfikat nie zwalnia z dalszych pytań. Warto ustalić: czego dokładnie dotyczy (które usługi, które regiony), kto go wydał i czy jest aktualny. Komunikaty „jesteśmy zgodni z RODO” bez konkretów można traktować jako hasło marketingowe, nie dowód.
Lokalizacja i redundancja centrów danych
Dla wielu podmiotów medycznych kluczowe jest, aby dane były przetwarzane na terenie UE/EOG. Przy wyborze dostawcy chmury dobrze jest uzyskać jasną informację:
w jakich fizycznych lokalizacjach (regionach, strefach) będą przechowywane dane,
czy repliki i kopie zapasowe również pozostają w tym samym obszarze prawnym,
czy usługodawca wykorzystuje podwykonawców spoza UE i na jakich zasadach.
Istotna jest też redundancja: dwa niezależne centra danych w tym samym regionie lepiej zabezpieczają ciągłość działania niż pojedyncze centrum, nawet bardzo zaawansowane. Dla krytycznych systemów medycznych bywa stosowany scenariusz aktywne–pasywne, gdzie w razie awarii jednego ośrodka drugi przejmuje ruch.
Model odpowiedzialności dzielonej – kto za co odpowiada
Każdy poważny dostawca chmury opisuje tzw. shared responsibility model – podział odpowiedzialności między dostawcę a klienta. Zazwyczaj dostawca odpowiada za bezpieczeństwo chmury (infrastruktura, fizyczne centra danych, podstawowe mechanizmy bezpieczeństwa), a klient – za bezpieczeństwo w chmurze (konfiguracje, uprawnienia, zarządzanie użytkownikami, treść danych).
Przy wyborze dostawcy nie wystarczy obejrzeć ładnego diagramu. Trzeba przełożyć go na konkrety:
kto odpowiada za aktualizacje systemów operacyjnych i baz danych,
kto konfiguruje backup i testuje odtwarzanie,
kto reaguje na incydenty bezpieczeństwa i w jakim czasie,
co dokładnie jest objęte SLA (tylko „czas dostępności”, czy też reakcja na incydent).
Mechanizmy bezpieczeństwa dostępne „w pakiecie”
Przy danych medycznych warto sprawdzić, jakie funkcje bezpieczeństwa są dostępne standardowo, a za co trzeba zapłacić osobno. Przykłady istotnych mechanizmów:
uwierzytelnianie wieloskładnikowe (MFA) dla kont administracyjnych i użytkowników,
rejestrowanie i analiza logów (kto się logował, jakie operacje wykonywał),
mechanizmy DLP (Data Loss Prevention) wykrywające nietypowe ruchy z danymi,
automatyczne skanowanie konfiguracji pod kątem luk (np. publicznie dostępne zasoby, słabe hasła),
opcje szyfrowania z zarządzaniem kluczami po stronie klienta.
Im więcej z tych funkcji jest zintegrowanych i dostępnych bez konieczności budowania wszystkiego od zera, tym łatwiej faktycznie wdrożyć sensowny poziom bezpieczeństwa, a nie tylko opisać go w polityce.
Wsparcie i reagowanie na incydenty
Oprócz parametrów technicznych liczy się jakość wsparcia operacyjnego. Dobrze zadać kilka bardzo przyziemnych pytań:
jak zgłasza się incydenty bezpieczeństwa i awarie (telefon, portal, e-mail),
Parametry SLA i przerwy serwisowe w praktyce
SLA (Service Level Agreement) przy danych medycznych to coś więcej niż ładny procent w prezentacji sprzedażowej. Deklaracja „99,9% dostępności” niewiele znaczy, jeśli okienka serwisowe wypadają akurat wtedy, gdy przyjmowani są pacjenci lub prowadzone są planowe zabiegi.
Przy analizie SLA dopytaj o szczegóły:
definicję „dostępności” – czy oznacza ona dostępność całej usługi, czy tylko warstwy sieciowej,
planowane przerwy techniczne – jak często, jak wcześnie są zapowiadane, czy można je uzgadniać indywidualnie,
czasy reakcji i usunięcia awarii – oddzielnie dla incydentów krytycznych (np. brak dostępu do EDM) i mniej istotnych,
mechanizm eskalacji – kto faktycznie odbierze telefon, gdy pacjenci stoją w kolejce, a system „leży”.
Mit bywa taki, że „duży dostawca = wszystko zawsze działa”. Rzeczywistość jest bardziej przyziemna: awarie zdarzają się wszystkim, kluczowe jest, jak szybko i transparentnie są obsługiwane oraz na ile plan przerw jest zsynchronizowany z rytmem pracy placówki.
Audytowalność i przejrzystość działań dostawcy
Przy dokumentacji medycznej audyt nie jest fanaberią, tylko obowiązkiem. Przechodząc do chmury, trzeba sprawdzić, czy dostawca umożliwia realną kontrolę – również z perspektywy przyszłych kontroli organów nadzorczych.
Przy rozmowach z dostawcą doprecyzuj:
jakie raporty bezpieczeństwa i zgodności są dostępne (np. wyniki audytów, raporty typu SOC, informacje o testach penetracyjnych),
czy możliwe są audty na miejscu lub zdalne po stronie klienta albo jego zewnętrznego audytora,
w jaki sposób dostawca informuje o incydentach bezpieczeństwa dotyczących infrastruktury,
czy rejestrowane są operacje administracyjne po stronie dostawcy (kto, kiedy, co skonfigurował).
Czasem pojawia się przekonanie: „w chmurze nic nie zobaczę, bo wszystko jest ukryte”. U poważnych dostawców proporcja jest odwrotna – logów i śladów jest zwykle więcej niż w lokalnej serwerowni, trzeba tylko umieć je wykorzystać i sensownie archiwizować.
Źródło: Pexels | Autor: Valeria Nikitina
Umowa powierzenia i dokumentacja formalna – co musi się w niej znaleźć
Rola administratora a rola procesora – uniknięcie „szarej strefy”
Przy przechowywaniu dokumentacji medycznej większość placówek pozostaje administratorem danych, a dostawca chmury staje się procesorem (podmiotem przetwarzającym). Umowa powierzenia ma jasno to odzwierciedlać, bez prób „przerzucenia” odpowiedzialności za całość przetwarzania na dostawcę.
W umowie szukaj zapisów, które precyzują:
kto jest administratorem danych i za jakie decyzje odpowiada (cele, zakres, kategorie danych),
jakie operacje przetwarzania realizuje dostawca chmury – konkretnie, nie ogólnikowo,
że dostawca przetwarza dane wyłącznie na udokumentowane polecenie administratora,
jak wygląda łańcuch podwykonawców (sub-procesorów) i jak administrator jest o nich informowany.
Mit: „Skoro mam umowę powierzenia, to odpowiedzialność za bezpieczeństwo jest po stronie chmury”. Rzeczywistość: administrator nadal odpowiada za zgodność przetwarzania z prawem, dobór procesora oraz nadzór nad tym, jak dane są zabezpieczone.
Zakres i cel przetwarzania – precyzja zamiast ogólników
W dokumentacji formalnej nie wystarczą hasła typu „przetwarzanie danych w celu świadczenia usługi”. Dla dokumentacji medycznej zakres powinien być opisany tak, aby z zewnątrz było jasne, co faktycznie dzieje się z danymi.
Dobrą praktyką jest wskazanie wprost:
kategorii danych (dane dotyczące zdrowia, dane identyfikacyjne pacjentów, dane personelu, logi dostępu),
celów pomocniczych – np. utrzymanie i rozwój systemu, testy, monitorowanie działania usług.
W części dostawców można spotkać ogólne wzorce umów, w których wszystkie te elementy są zlane w jedno zdanie. Przy danych medycznych opłaca się poświęcić czas na doprecyzowanie zapisów, nawet jeśli wymaga to kilku iteracji z działem prawnym po obu stronach.
Środki techniczne i organizacyjne – jak przełożyć „zgodność z normami” na konkret
Zapisy typu „dostawca stosuje adekwatne środki techniczne i organizacyjne zgodnie z najlepszymi praktykami branżowymi” brzmią ładnie, ale w razie incydentu są trudne do obrony. W umowie powierzenia i załącznikach warto zejść poziom niżej.
Przykładowe obszary, które można ująć konkretniej:
kontrola dostępu – wymagane mechanizmy uwierzytelniania, MFA, zasady nadawania uprawnień,
szyfrowanie – minimalne standardy dla danych w spoczynku i w tranzycie, sposób zarządzania kluczami,
kopie zapasowe – częstotliwość, czas przechowywania, wymagania dotyczące testów odtworzeniowych,
monitoring i logowanie – zakres rejestrowanych zdarzeń, czas retencji logów, zasady udostępniania logów administratorowi,
kontrola podwykonawców – minimalne wymagania bezpieczeństwa wobec sub-procesorów.
Mit pojawia się wtedy, gdy ktoś wierzy, że formuła „zgodnie z ISO/IEC 27001” załatwia temat. Norma jest ramą, a nie listą checkboxów. To szczegółowe ustalenia i ich egzekwowanie decydują, czy system faktycznie jest odporny.
Transfer danych poza EOG i dostęp służb – czego wymagać od dostawcy
Przy wielu rozwiązaniach chmurowych pojawia się pytanie o potencjalny transfer danych poza EOG oraz ewentualny dostęp organów państwowych spoza UE. To wrażliwy temat, zwłaszcza przy danych o stanie zdrowia, ale nie da się go zamieść pod dywan jednym zdaniem o „przetwarzaniu w UE”.
W dokumentacji i umowie powierzenia należy jasno określić:
czy dane (także kopie zapasowe i logi) będą przetwarzane wyłącznie w regionach UE/EOG,
czy dostawca przewiduje transfer danych do państw trzecich – jeśli tak, na jakiej podstawie prawnej (np. standardowe klauzule umowne),
jak dostawca informuje administratora o żądaniach organów publicznych dotyczących dostępu do danych, o ile nie jest to prawnie zakazane,
jakie środki techniczne ograniczają możliwość dostępu do danych (np. silne szyfrowanie z kluczami po stronie klienta).
W praktyce część organizacji decyduje się na model, w którym krytyczne dane medyczne są dodatkowo szyfrowane własnymi kluczami, tak aby nawet dostawca chmury nie miał możliwości ich odszyfrowania bez udziału administratora. To nie jest „srebrna kula”, ale sensowna warstwa obrony.
Procedury reagowania na incydenty i naruszenia danych osobowych
Przy danych medycznych czas reakcji na incydent ma wpływ nie tylko na zgodność z RODO, lecz także na ciągłość opieki. W umowie z dostawcą chmury trzeba jasno mieć opisane, co się dzieje, gdy coś pójdzie nie tak.
Elementy, które powinny zostać uregulowane:
kanały komunikacji w przypadku incydentu (24/7, kontakt awaryjny, osoby odpowiedzialne po obu stronach),
maksymalne czasy reakcji dla incydentów o różnej wadze,
zakres współpracy przy analizie incydentu – dostęp do logów, wsparcie zespołów bezpieczeństwa,
sposób szacowania skutków dla osób, których dane dotyczą (pacjentów, personelu),
obowiązek udzielenia informacji potrzebnych administratorowi do zgłoszenia naruszenia organowi nadzorczemu.
W wielu realnych przypadkach problemem nie jest samo naruszenie, lecz chaos informacyjny: brak jasnego właściciela po stronie dostawcy, rozproszone logi i niejednoznaczny opis zdarzenia. Im więcej szczegółów doprecyzowanych w umowie i procedurach, tym mniej improwizacji pod presją czasu.
Retencja, usuwanie i przenoszalność danych
Dokumentacja medyczna ma ustawowo określone okresy przechowywania, ale świat chmury rządzi się dodatkowymi zasadami: snapshoty, kopie awaryjne, logi, dane w systemach cache. Jeżeli retencja nie zostanie dobrze zaprojektowana, łatwo dojść do sytuacji, w której „formalnie usunięte” dane nadal istnieją w kilku zakamarkach infrastruktury.
Przy ustalaniu zasad retencji i usuwania ustal z dostawcą:
jakie są okresy przechowywania dla poszczególnych kategorii danych (produkcyjne, backupy, logi),
jak wygląda proces trwałego usuwania (w tym z kopii zapasowych) po upływie okresu retencji lub na żądanie administratora,
czy istnieją techniczne ograniczenia w przyspieszonym usuwaniu danych z backupów,
w jaki sposób realizowana jest przenoszalność danych przy zmianie dostawcy lub zakończeniu współpracy (format, terminy, koszty).
Mit polega często na założeniu, że „jak kliknę usuń w aplikacji, to danych już nie ma”. W złożonych środowiskach chmurowych to tylko początek procesu. Administrator danych musi wiedzieć, jak ten proces wygląda w szczegółach i jakie są jego granice techniczne.
Szkolenia i świadomość personelu – najtańszy, ale często zaniedbany środek bezpieczeństwa
Nawet najlepiej napisana umowa powierzenia i perfekcyjnie skonfigurowana chmura nie ochronią dokumentacji medycznej przed błędami ludzkimi. To nie jest truizm, tylko obserwacja z wielu incydentów, gdzie źródłem problemu okazywał się np. lekarz korzystający z prywatnego laptopa bez aktualnych łatek lub hasło do konta administracyjnego zapisane na karteczce.
Warto wprost ująć w dokumentacji wewnętrznej placówki:
jakie szkolenia z bezpieczeństwa przechodzi personel medyczny i administracyjny,
jak są weryfikowane uprawnienia przy zmianach stanowisk, odejściach z pracy, zakończeniu współpracy z kontraktorem,
jakie są zasady korzystania z urządzeń prywatnych (BYOD) i zdalnego dostępu do systemów w chmurze,
jak przebiega proces zgłaszania incydentów przez użytkowników pierwszej linii (rejestracja, pielęgniarki, lekarze), aby nie bali się „podpaść” zgłoszeniem problemu.
Chmura często bywa obwiniana za incydenty, które w rzeczywistości wynikają z braku podstawowej higieny bezpieczeństwa po stronie użytkowników. Lepsze przeszkolenie i proste, zrozumiałe procedury potrafią ograniczyć ryzyko skuteczniej niż kolejna warstwa technicznych gadżetów.
Co warto zapamiętać
Przeniesienie dokumentacji medycznej do chmury zwiększa ciągłość działania placówki: eliminuje pojedynczy serwer „w piwnicy”, zapewnia redundancję, profesjonalne kopie zapasowe i szybkie odtwarzanie po awarii.
Największy praktyczny zysk to dostępność danych z każdego gabinetu i lokalizacji oraz podczas pracy zdalnej – lekarz ma w jednym miejscu historię choroby, wyniki badań, zdjęcia i opisy hospitalizacji, bez pendrive’ów i maili.
Model chmurowy obniża i porządkuje koszty IT: zamiast dużych jednorazowych inwestycji w serwery, macierze, klimatyzację i zasilanie awaryjne pojawia się przewidywalna opłata abonamentowa skalowana do rzeczywistych potrzeb.
Chmura umożliwia scenariusze, które lokalnie są praktycznie niewykonalne: integrację wielu przychodni w jedną platformę, centralne call center i rejestrację online, teleporady, hurtownię danych czy automatyczne kierowanie pacjentów do wolnych specjalistów.
Mit, że „serwer w szafie jest bezpieczniejszy niż chmura”, zderza się z rzeczywistością: brak łatek, monitoringów, szyfrowania i procedur w małej serwerowni zwykle oznacza niższy poziom bezpieczeństwa niż u profesjonalnego dostawcy chmury.
Brak chmury wcale nie zmniejsza ryzyka – wręcz przeciwnie: pojedynczy punkt awarii, kradzież lub utrata sprzętu z lokalnymi danymi oraz przestarzałe, nieaktualizowane systemy dramatycznie zwiększają szanse na incydent bezpieczeństwa lub utratę danych.
Opracowano na podstawie
Wytyczne dotyczące przetwarzania danych osobowych w chmurze obliczeniowej. Urząd Ochrony Danych Osobowych (2020) – Wytyczne UODO nt. chmury i danych osobowych, w tym medycznych
RODO. Ogólne rozporządzenie o ochronie danych osobowych. Parlament Europejski i Rada UE (2016) – Podstawy prawne przetwarzania i zabezpieczenia danych osobowych pacjentów
Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta. Sejm Rzeczypospolitej Polskiej (2008) – Obowiązki placówek w zakresie dokumentacji medycznej i jej ochrony
ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems. International Organization for Standardization (2022) – Norma zarządzania bezpieczeństwem informacji, stosowana w centrach danych i chmurze
