Zaprojektowane z myślą
o sektorze publicznym
Dostęp liczony po stronie serwera i dodatkowo pilnowany przez bazę danych, audyt z kontrolą integralności, ochrona danych pacjenta już na etapie wpisywania — od pierwszej linii kodu, nie jako dodatek na końcu.
Określa dozwolony typ operacji w systemie — administrator centralny, WKRM, koordynator szpitala i tak dalej.
Województwo, podmiot, oddział lub dyspozytornia — dokładnie tyle, do ilu osoba ma aktywne przypisanie w wybranej sesji.
Każde żądanie musi dotyczyć zasobu z zakresu aktywnego przypisania — sprawdza to serwer, a granice województw dodatkowo baza danych.
Operacje z katalogu audytowego, w tym działania administratora centralnego, trafiają do rejestru z kontrolą integralności.
Dane pacjenta — trzy warstwy ochrony
WIDOK RM nie jest dokumentacją medyczną i nie potrzebuje danych pacjenta. Dlatego system nie polega na samym ostrzeżeniu w interfejsie.
1. Blokada przy wpisywaniu
Opisy w ZDLP i w uzgadnianiu przyjęć są sprawdzane pod kątem PESEL, numeru dokumentu, telefonu, adresu, e-maila i możliwego imienia i nazwiska. Taki opis zostaje odrzucony z wyjaśnieniem, co poprawić.
2. Audyt bez treści
Dziennik zdarzeń zapisuje metrykę operacji i skrót żądania, a nie jego treść — więc nie staje się kopią informacji klinicznych.
3. Maskowanie
Dodatkowo, gdy wartość wrażliwa trafia do zapisów technicznych, jest maskowana przed zapisem.
| Pole | Wartość źródłowa | Zapis po maskowaniu |
|---|---|---|
| Kontekst pacjenta | Pacjent: Jan Kowalski | Pacjent: J** K******* |
| PESEL | 12345678901 | 123456***** |
Kod ICD-10 dołączany opcjonalnie do zapytania o przyjęcie jest widoczny wyłącznie dla stron sprawy i nie zawiera danych identyfikujących. Obsada zespołów to liczby kompetencji, a dyspozytorzy występują w widokach operacyjnych pod numerem służbowym.
Tożsamość, sesja i autoryzacja
Uwierzytelnianie
Wydzielona warstwa Keycloak obsługuje tożsamość i MFA/TOTP. Operacje wymagające podwyższonego zaufania wymagają świeżego potwierdzenia drugim składnikiem.
Uprawnienia i zakres
Użytkownik wybiera na początku sesji rolę i zakres. API weryfikuje rolę, aktywne przypisanie i kontekst organizacyjny, a Row Level Security w PostgreSQL w trybie wymuszonym pilnuje granic danych.
Cykl dostępu
Delegacje uprawnień z terminem, cykliczna recertyfikacja, centrum sesji i wyjaśnienie, z czego wynika dostęp konkretnej osoby.
To opis mechanizmów aplikacji, nie certyfikat zgodności. Publiczny wybór roli w demo nie testuje produkcyjnego uwierzytelniania. Ocena ryzyka, konfiguracja, testy i odbiór pozostają elementem wdrożenia.
Warstwy bezpieczeństwa dotyczą nie tylko logowania
Izolacja województw
Każde województwo może działać jako odizolowany segment z własnym certyfikatem. Widok centralny czyta segmenty podpisanym, wyłącznie odczytowym kanałem — przejęcie jednego segmentu nie otwiera pozostałych.
Niezmienna historia
Historia zapytań, odpowiedzi, uzgodnień i rezerwacji przyjęć jest chroniona w bazie: aplikacja może ją tylko uzupełniać, nie zmieniać ani usuwać.
Analityka bez obejść
Każda miesięczna część tabeli wyników dostaje ochronę automatycznie w chwili powstania; wyniki dotyczą jednostek, a małe grupy chroni próg.
Załączniki
Pliki do 10 MB są skanowane antywirusowo. Gdy skaner jest niedostępny, plik zostaje odrzucony — nigdy przyjęty bez sprawdzenia.
Ochrona przed nadmiarem żądań
Limity na adres i na użytkownika; przy chwilowym przeciążeniu system prosi o ponowienie zamiast zgłaszać błąd.
Outbox i kolejki
Zdarzenie i wiadomość zapisywane w jednej transakcji; eskalacja działa niezależnie od otwartej karty przeglądarki.
Jak działa łańcuch audytowy
- Rejestr tylko do dopisywania; każdy wpis jest powiązany kryptograficznie z poprzednim — podmiana lub usunięcie wpisu przerywa łańcuch w sposób wykrywalny
- Rejestr rotuje do nowego segmentu po 1000 wpisów, bez kasowania poprzednich danych
- Sekret HMAC nie jest przechowywany w kodzie źródłowym aplikacji
- Krytyczne błędy techniczne są widoczne wyłącznie dla administratora centralnego
RODO i minimalizacja danych
- System przechowuje stan jednostek i przebieg procesów, nie dane pacjentów
- Dane ćwiczeń i testów technicznych oddzielone od danych realnych
- Docelowa wymiana z EZD RP ogranicza się do metadanych i referencji — WIDOK RM nie kopiuje dokumentacji
- Klasyfikacja SCCO ustalana wspólnie z urzędem przed uruchomieniem produkcyjnym
Odbiór wersji 2.0
Przed ogłoszeniem wydania stabilnego system przeszedł pełny audyt i pomiar obciążenia.
- Testy w wariantach z modułami opcjonalnymi wyłączonymi i włączonymi
- Sprawdzenie izolacji: nie znaleziono żadnej drogi danych między województwami
- Odtworzenie środowiska z kopii zapasowej sprawdzone w praktyce
- Pomiar na danych szesnastu województw: bez błędów przy 72 równoczesnych użytkownikach
- Każda migracja bazy produkcyjnej poprzedzona kopią i kontrolą zgodności danych przed i po zmianie
Co jest w systemie, a co ustala się z urzędem
Opisane mechanizmy są częścią aktualnego systemu. Rozwój każdego z nich opisuje historia wydań. Uruchomienie w danym urzędzie obejmuje dodatkowo uzgodniony model SLA, RTO i RPO, test odtwarzania w docelowym środowisku, niezależny monitoring i procedury incydentowe — ustalane wspólnie z urzędem przed startem.
Pytania o bezpieczeństwo i zgodność?
Chętnie przejdziemy przez architekturę bezpieczeństwa razem z Twoim zespołem IT.