14.5. Prowadzenie e-dokumentacji i ochrona danych osobowych (RODO)

2. Struktura elektronicznej karty pacjenta i przydział ról/dostępów

A. Zasady projektowe elektronicznej karty pacjenta (E-KP)

Modularność i warstwowanie — karta powinna być podzielona na odrębne moduły tematyczne, które można włączać/wyłączać zależnie od potrzeb gabinetu i uprawnień użytkownika: dane identyfikacyjne, wywiad, historia chorób, bieżąca sesja/epizod, zakładka procedur (bańkowanie), obrazy/zdjęcia, załączniki (skany, wyniki badań), plan terapeutyczny, zgody i notatki prywatne. Modularny układ ułatwia minimalizację dostępu (zasada najmniejszej konieczności).
Jednoźródłowość danych — każda informacja ma jedną „kanoniczną” wersję w systemie; inne widoki (np. formularz skrócony dla recepcji) odwołują się do tej wersji, nie kopiują danych. Zmiana raz wprowadzona propaguje się w widokach zależnych (zachowując wersjonowanie).
Metadane i kontekst kliniczny — każde pole musi przechowywać metadane: kto wprowadził, data/godzina, kontekst (np. „wywiad przyjęcia”, „notatka po zabiegu”), status (wstępny/zweryfikowany/potwierdzony). To umożliwia późniejszą walidację i filtrowanie informacji.
Sekcje strukturyzowane i wolne notatki — tam gdzie możliwe stosować pola strukturyzowane (lista wartości, skale, checkboxy) by ułatwić analizę i raportowanie; nadal dopuszczać wolne notatki kliniczne, ale z oznaczeniem autora i znacznikiem dla przeglądu (np. „do weryfikacji przez lekarza”).
Powiązania między modułami — elementy karty powinny mieć mechanizm powiązań (np. zgoda X jest powiązana z epizodem zabiegu Y i zdjęciami Z). Dzięki temu przy przeglądaniu epizodu terapeutycznego widoczny jest kompletny kontekst.
Szablony i protokoły — E-KP powinna mieć możliwość tworzenia i stosowania szablonów: karta przyjęcia, karta zabiegowa dla serii bańkowania, formularz oceny przed/po. Szablony przyspieszają pracę i poprawiają spójność dokumentacji.
Pole „ważne alerty” — zawsze widoczne u góry karty: alergie, przeciwwskazania, istotne ograniczenia prawne (np. brak zgody na zdjęcia) oraz instrukcje „kto powiadomić” w razie nagłego zdarzenia.
Identyfikatory i powiązanie z systemami zewnętrznymi — każdy pacjent i każdy epizod powinny mieć unikalny identyfikator (UUID) i możliwość powiązania z dokumentacją zewnętrzną (np. numer z systemu szpitalnego) w sposób bezpieczny i audytowany.
Maszyna stanu (statusy epizodu) — epizody (np. seria zabiegów) mają predefiniowane statusy: zaplanowane, w toku, zakończone, przerwane, przekazane dalej. Status wpływa na widoczność i prawa edycji.
Mechanizmy prywatności i oznaczeń edukacyjnych/badawczych — oddzielne flagi, które oznaczają dane do użytku wewnętrznego, do badań/anonimizacji, do prezentacji edukacyjnej (tylko po anonimizacji i zgodach).

B. Pola i struktury danych — szczegóły logiczne

Dane identyfikacyjne: imię i nazwisko, PESEL (lub inny identyfikator), data urodzenia, kontakt, osoba kontaktowa, informacje prawne (pełnomocnictwa).
Wywiad medyczny strukturyzowany: przebyte choroby, zabiegi, leki, alergie, wskazania/przeciwwskazania do bańkowania, ryzyka związane z procedurą. Każda odpowiedź powinna mieć pole „data ostatniej aktualizacji”.
Episod/Seans terapeutyczny: data/godzina, terapeuta, technika (suche/mokre), lista użytych baniek, parametry (czas, ciśnienie jeśli mierzone), lokalizacje anatomiczne, reakcje bezpośrednie. Pole „wynik subiektywny pacjenta” (np. skala bólu przed/po).
Obrazy i multimedia: standardowy nagłówek z metadanymi: autor, miejsce wykonania, ustawienia aparatu, odległość od punktu odniesienia — ułatwia porównania. System powinien wymuszać minimalną kompresję i format zapewniający jakość przy archiwizacji.
Plan terapeutyczny i zadania: elementy zadaniowe przypisane do ról (np. „fizjoterapeuta X — kontrola za 7 dni”), harmonogram, przypomnienia dla pacjenta.
Zgody i dokumentacja prawna: pełna treść zgody, wersja dokumentu, podpis elektroniczny lub inna forma weryfikacji, data, powiązanie z epizodem.
Notatki i rekomendacje: podział na notatki widoczne dla pacjenta (jeśli udostępnione) i notatki wewnętrzne (tylko personel).
Tagi kliniczne i klasyfikacje: możliwość etykietowania (np. ICD-10, kody procedur) ułatwiająca raportowanie i wyszukiwanie przypadków do audytu.

C. Model przydziału ról i uprawnień — praktyczny model

Role podstawowe (przykładowe):
- Rejestracja — dostęp do danych identyfikacyjnych, umawianie wizyt, przegląd ograniczony epizodów (bez notatek klinicznych).
- Terapeuta — pełny dostęp do epizodu terapii, możliwość wprowadzania danych zabiegowych i planów; dostęp do zdjęć związanych z zabiegiem.
- Lekarz nadzorujący — możliwość weryfikacji notatek terapeuty, edycji planu leczenia, zatwierdzania zgód medycznych.
- Administrator systemu — zarządzanie użytkownikami i konfiguracją (bez dostępu do danych medycznych pacjentów w trybie „bezpośrednim” — dostęp wymaga ścisłych procedur).
- Audytor/Inspektor — dostęp do audytu zdarzeń i wersji dokumentów w zakresie wskazanym przez procedury prawne.
- Pacjent (portal) — dostęp do wybranych danych: epizody, zgody, zdjęcia (jeśli zgoda), wyniki; możliwość pobrania dokumentacji.
Zasada najmniejszego przywileju — każdej roli przypisuje się jedynie niezbędne prawa (czytanie/edycja/wyeksport) do określonych modułów karty. Uprawnienia muszą być szczegółowe na poziomie pól (np. terapeuta może edytować „epizod” ale nie może zmieniać „wywiadu podstawowego” bez zgody lekarza).
Uprawnienia warunkowe i czasowe — możliwość przydzielenia praw tymczasowych (np. specjalista zewnętrzny ma dostęp tylko przez 72 godziny do jednego epizodu).
Procedura „awaryjnego dostępu” (break-glass) — w sytuacjach nagłych istnieje mechanizm tymczasowego rozszerzenia praw (dostęp awaryjny), który zawsze jest audytowany i wymaga wpisania uzasadnienia oraz powiadomienia odpowiedzialnej osoby nadzorującej.
Mapowanie ról na konkretne czynności — dla każdej czynności w systemie (np. „podpisz zgodę”, „dodaj zdjęcie”, „zamknij epizod”) zdefiniować, które role mają prawo do wykonania tej czynności, a które jedynie do jej przeglądu.
Proces nadawania i cofania uprawnień — formalny workflow: wniosek → akceptacja przełożonego → przydział przez administratora → automatyczne cofnięcie po terminie lub przy zmianie stanowiska. Wszystkie zmiany audytowane.
Szczegółowy poziom pól wrażliwych — niektóre pola (np. informacje o zdrowiu psychicznym, zdjęcia intymne) powinny mieć restrykcje dodatkowe i wymagać wyraźnej zgody pacjenta na udostępnienie konkretnym rolom.

D. Mechanizmy techniczne wspierające politykę dostępu

Widoki kontekstowe — interfejs pokazuje użytkownikowi tylko te pola, do których ma prawo. Brak uprawnień = pole niewidoczne (lepsze od „szarego” lub „zablokowanego”).
Maskowanie danych — w widokach pomocniczych (np. raporty statystyczne) automatyczne maskowanie danych osobowych.
Delegacja uprawnień i zastępstwa — możliwość upoważnienia innego pracownika do dostępu na czas nieobecności (delegacja audytowana).
Weryfikacja tożsamości przed krytycznymi operacjami — przy wydruku medycznym, usunięciu danych, nadaniu praw — dodatkowy krok potwierdzający (np. 2FA lub hasło jednorazowe).

E. Raportowanie i audyt dostępów

Raporty dostępu — możliwość wygenerowania raportu kto, kiedy i do jakich danych miał dostęp — z podziałem na role i rodzaj operacji.
Automatyczne alerty — system może generować alerty przy nietypowych działaniach (np. dostęp do dużej liczby kart w krótkim czasie) i wysyłać do opiekuna bezpieczeństwa.
Okresowe przeglądy uprawnień — cykliczne (np. kwartalne) przeglądy nadanych uprawnień z potwierdzeniem potrzeb.

F. Integracja z prawami pacjenta i RODO w kontekście dostępu

Mechanizmy realizacji żądań pacjenta — funkcje udostępnienia, eksportu i usunięcia danych wykonywane przez użytkowników z odpowiednimi uprawnieniami i dokumentowane w rejestrze żądań.
Zgody na udostępnianie — każde udostępnienie danych zewnętrznych powinno być związane z konkretną zgodą lub prawnie uzasadnionym podstawem, z zapisem kto i kiedy udostępnił.
Logika minimalnego udostępniania — przy wysyłaniu danych zewnętrznie system podpowiada minimalny zakres wymagany do celu (np. konsultacja ortopedyczna wymaga epizodu i zdjęć, nie całej historii).

Krótki przykład

Pacjent „A.” zgłasza się z bólem krzyża. W E-KP powstaje epizod „Ból lędźwiowy — 2025-11-22”: terapeuta wprowadza szczegóły zabiegu (typ baniek, lokalizacje, czas), dołącza zdjęcie skóry przed i po zabiegu, wypełnia formularz zgody (z e-podpisem pacjenta). Role: terapeuta ma prawo edycji epizodu; rejestracja widzi tylko dane kontaktowe i umówione terminy; lekarz nadzorujący może przeglądać i zatwierdzić plan dalszego leczenia. Jeśli pacjent zgodzi się na publikację przypadku edukacyjnego, administrator anonimizuje dane i nadaje dostęp do tego zbioru tylko użytkownikom z rolą „edukator”.

Krótkie ćwiczenie praktyczne (czas 20–30 minut)

Materiały: drukowane (albo w notatniku) proste pola karty: (A) dane identyfikacyjne, (B) wywiad, (C) epizod zabiegowy, (D) zdjęcia, (E) zgody, (F) notatki wewnętrzne.
Zadanie — Macierz dostępów (10–15 min): narysuj tabelę 6×6 (kolumny = pola A–F, wiersze = role: rejestracja, terapeuta, lekarz, administrator, audytor, pacjent). Dla każdej komórki wpisz R (read), W (write), N (no access). Kieruj się: rejestracja = A:RW, B:N, C:N, D:N, E:N, F:N; terapeuta = A:R, B:R/W, C:R/W, D:R/W, E:R (tylko powiązane zgody), F:W; lekarz = A:R, B:R/W, C:R, D:R, E:R/W, F:R; pacjent = A:R, B:R (wybrane), C:R (epizody), D:R (jeśli zgoda), E:R/W (swoje zgody), F:N.
Refleksja (5–10 min): zaznacz trzy miejsca w macierzy, które budzą wątpliwość (np. pacjent — dostęp do notatek wewnętrznych?). Zapisz krótkie uzasadnienie: dlaczego dostęp powinien być ograniczony i jaki mechanizm kontroli dodałbyś (np. wymóg zgody, dodatkowe zatwierdzenie lekarza, logowanie „break-glass”).

Wynik ćwiczenia wprowadź do procedury lokalnej jako propozycję polityki przydziału ról — dokument ten może być potem wykorzystany przy konfiguracji systemu e-dokumentacji.