Krótka odpowiedź: bezpieczeństwo w aplikacji zdrowotnej odpowiada na cztery pytania, w kolejności. Kto to jest? Tożsamość: zweryfikowany użytkownik (pacjent, lekarz, system) za pomocą OpenID Connect, a w przypadku lekarzy – krajowej tożsamości zawodowej; poziom weryfikacji jest ważniejszy niż siła hasła. Co mogą robić? Autoryzacja: tokeny OAuth 2.0 (przechodzące do 2.1) z zakresami w składni SMART on FHIR, pochodzące z zgody pacjenta na określony cel i czas, egzekwowane na poziomie danych. Co zrobili? Odpowiedzialność: log dostępu, który pacjent może odczytać, oraz ścieżka audytu FHIR AuditEvent dla organizacji. Czy dane są bezpieczne w spoczynku, w tranzycie i w kopiach zapasowych? Ochrona: szyfrowanie, zarządzanie kluczami, segregacja, przetestowane przywracanie. Wokół nich: podstawa ISO 27001 i 27799, NIS2 i Zasada Bezpieczeństwa HIPAA, a także specyficzne zagrożenia związane z danymi medycznymi (przeglądanie przez osoby nieuprawnione, błędne przypisywanie, ransomware).
Mapa
Bezpieczeństwo i tożsamość w aplikacji zdrowotnej składają się z siedmiu warstw: tożsamość poprzez OpenID Connect oraz identyfikatory krajowe lub zawodowe, autoryzacja poprzez OAuth 2.0 i zakresy SMART on FHIR, zgoda jako źródło każdego uprawnienia, odpowiedzialność poprzez logi dostępu i FHIR AuditEvent, ochrona poprzez szyfrowanie i kopie zapasowe, podstawę stanowią ISO 27001, ISO 27799, NIS2 i HIPAA, oraz udostępnianie inicjowane przez pacjenta.
| Warstwa | Standard lub praktyka | Co zapewnia | Strona |
|---|---|---|---|
| Tożsamość | OpenID Connect; krajowe dowody tożsamości (eIDAS, NHS login, GesundheitsID); tożsamości zawodowe (eHBA, CPS, UZI) | Zweryfikowany podmiot z poziomem zapewnienia | Wyjaśnienie SMART App Launch |
| Autoryzacja | OAuth 2.0 i 2.1 (PKCE obowiązkowe, brak grantów typu implicit lub password); zakresy SMART on FHIR (patient/Observation.rs); usługi backend z asymetrycznym uwierzytelnianiem klienta | Tokeny powiązane z użytkownikiem, kontekstem pacjenta i zakresem | Wyjaśnienie SMART App Launch, Backend SMART on FHIR |
| Zgoda | FHIR Consent; zgody ograniczone czasowo i celowo; cofnięcie; dostęp w nagłych wypadkach („break-the-glass”) z uzasadnieniem i powiadomieniem | Pacjent jako źródło każdej autoryzacji | Platforma zgody pacjenta, Prośby o dostęp z kliniki |
| Odpowiedzialność | Logi dostępu do poszczególnych rekordów widoczne dla pacjenta; FHIR AuditEvent; zabezpieczone przed manipulacją przechowywanie; retencja | Kto, co, kiedy, dlaczego widział | Kto przeglądał moją dokumentację medyczną? |
| Ochrona | TLS 1.2+, szyfrowanie w spoczynku z zarządzanymi kluczami, szyfrowanie na poziomie pól dla identyfikatorów, segregowane środowiska, kopie zapasowe z przetestowanym przywracaniem | Poufność i dostępność | ISO 27001 vs ISO 27799 |
| Podstawa | ISMS ISO 27001, kontrolki zdrowotne ISO 27799, środki NIS2, Zasada Bezpieczeństwa HIPAA, krajowe schematy (HDS, DSPT, C5) | Czego oczekują szpitale, audytorzy i regulatorzy | NIS2 dla szpitali i dostawców, HIPAA vs GDPR |
| Udostępnianie | SMART Health Links i Cards; weryfikowalne poświadczenia | Udostępnianie inicjowane przez pacjenta za pomocą linku lub kodu QR, z możliwością cofnięcia | Wyjaśnienie SMART Health Links |
Tożsamość: zapewnienie ponad hasła
Tożsamość w aplikacji zdrowotnej zależy od pewności, a nie od siły hasła: poziomy pewności tożsamości, takie jak NIST IAL, eIDAS substantial i high, lub NHS login P9, opisują, jak silnie osoba została zweryfikowana podczas rejestracji, podczas gdy uwierzytelnianie wieloskładnikowe i klucze dostępu opisują każde logowanie. Pracownicy służby zdrowia są identyfikowani poprzez tożsamości zawodowe, które są unieważniane, gdy odchodzą.
Aplikacja pacjenta, która wyświetla pełną dokumentację, musi wiedzieć, że rozmawia z tym konkretnym pacjentem. Poziomy zapewnienia tożsamości (IAL NIST, eIDAS na poziomie znaczącym i wysokim, NHS login P9) opisują, jak silnie tożsamość została zweryfikowana podczas rejestracji; siła uwierzytelniania (wieloskładnikowe, klucze dostępu) opisuje każde logowanie. Szpitale i systemy krajowe coraz częściej wymagają zweryfikowanych tożsamości z uznanych schematów zamiast samodzielnie zgłaszanych rejestracji, a europejski portfel tożsamości cyfrowej stanie się akceptowalnym środkiem. W przypadku lekarzy tożsamość zawodowa (i jej cofnięcie po odejściu pracownika) jest systemem rejestrującym, kto w ogóle może działać jako lekarz.
Autoryzacja: zgoda staje się zakresami
Autoryzacja w rejestrze kontrolowanym przez pacjenta przekłada zgodę pacjenta, na przykład zezwolenie klinice na odczyt wyników laboratoryjnych i schorzeń przez 90 dni, na zakresy OAuth i kontekst pacjenta w tokenie, w składni SMART on FHIR, takiej jak patient/Observation.rs, egzekwowane na poziomie danych przy każdym żądaniu i unieważniane, gdy pacjent wycofa zgodę. "Break-the-glass" to oddzielna, audytowana ścieżka.
W dokumentacji kontrolowanej przez pacjenta, zgoda pacjenta jest polityką: ta klinika może odczytywać moje wyniki laboratoryjne i schorzenia przez 90 dni. System tłumaczy ją na zakresy OAuth i kontekst (który pacjent, które zasoby, które operacje) w tokenie, który otrzymuje system kliniki, egzekwuje je przy każdym żądaniu na poziomie danych i cofa je, gdy pacjent wycofa zgodę. Składnia zakresów SMART on FHIR (patient/Observation.rs, patient/Condition.rs) jest językiem uniwersalnym dla tego celu; szczegółowe zakresy (według kategorii lub kodu) istnieją w SMART v2 dla dokładniejszej kontroli. Dostęp w nagłych wypadkach („break-the-glass”) (dostęp awaryjny bez zgody pacjenta) to oddzielna, audytowana ścieżka z obowiązkowym uzasadnieniem i powiadomieniem pacjenta, nigdy nie jest to domyślna opcja. Zobacz Platforma zgody pacjenta.
Odpowiedzialność: log, który czyta pacjent
Odpowiedzialność w aplikacji zdrowotnej oznacza, że każdy dostęp do rekordu, przez kogo, kiedy, czego i na jakiej podstawie zgody, jest zapisywany w logu tylko do odczytu, który pacjent może przeglądać w swojej aplikacji, oraz w organizacyjnym śladzie audytu w FHIR AuditEvent. ISO 27799 traktuje to jako obowiązkowe, a widoczny log jest najsilniejszym środkiem odstraszającym od przeglądania danych przez osoby nieuprawnione.
Każdy dostęp do dokumentacji, przez kogo, kiedy, czego dotyczył, na jakiej podstawie zgody, zapisywany w logu tylko do odczytu, który pacjent może odczytać w swojej aplikacji, oraz w organizacyjnej ścieżce audytu (FHIR AuditEvent) dla zespołów ds. bezpieczeństwa. ISO 27799 traktuje to jako obowiązkowe dla informacji medycznych; zasada przejrzystości RODO i prawa pacjenta EHDS wskazują w tym samym kierunku; największym realnym odstraszaczem przed przeglądaniem przez osoby nieuprawnione jest widoczny log. Zobacz Kto przeglądał moją dokumentację medyczną?.
Ochrona: inżynieryjna podstawa
Podstawą inżynieryjną ochrony danych medycznych jest TLS wszędzie, szyfrowanie danych w spoczynku za pomocą zarządzanych, rotowanych kluczy, oddzielne szyfrowanie lub tokenizacja danych osobowych, odseparowane środowiska z syntetycznymi danymi poza produkcją, dostęp oparty na zasadzie najmniejszych uprawnień z uwierzytelnianiem wieloskładnikowym dla administratorów, zarządzanie sekretami i podatnościami, zaszyfrowane kopie zapasowe testowane przez przywracanie w celu ochrony przed ransomware oraz reagowanie na incydenty w ramach terminów GDPR i NIS2.
TLS wszędzie, z nowoczesnymi szyframi i przypinaniem certyfikatów w aplikacjach tam, gdzie to stosowne; szyfrowanie w spoczynku z kluczami w zarządzanej usłudze kluczy i rotacją; oddzielne szyfrowanie lub tokenizacja dla bezpośrednich identyfikatorów; segregacja środowiska produkcyjnego od deweloperskiego, z danymi syntetycznymi poza produkcją; dostęp oparty na zasadzie najmniejszych uprawnień dla personelu, brak współdzielonych kont, wieloskładnikowe uwierzytelnianie dla wszystkich dostępów administracyjnych; zarządzanie sekretami; zarządzanie zależnościami i podatnościami z ujawnianiem; kopie zapasowe szyfrowane, testowane przez przywracanie i chronione przed ransomware, które wielokrotnie dotykało szpitale i laboratoria (WannaCry w 2017, szpital w Düsseldorfie w 2020, Change Healthcare i Synnovis w 2024). Reagowanie na incydenty z 72-godzinnymi zegarami RODO i 24-godzinnymi zegarami NIS2 w jednym planie działania.
Zagrożenia specyficzne dla danych medycznych
Zagrożenia specyficzne dla danych medycznych to przeglądanie przez osoby nieuprawnione rekordów znajomych, błędne przypisywanie między pacjentami, zbyt szerokie udostępnianie udzielane na zbyt długi czas, SDK reklamowe w aplikacjach przetwarzających dane medyczne, wstrzykiwanie dokumentów do funkcji AI oraz długoterminowe przechowywanie przez dziesięciolecia, podczas którego klucze, formaty i zasady dostępu muszą przetrwać personel i dostawców.
- Przeglądanie przez osoby nieuprawnione dokumentacji znajomych lub osób publicznych: dostęp oparty na relacjach i widoczne logi.
- Błędne przypisywanie między pacjentami: uzgadnianie tożsamości i pochodzenie danych, nie tylko kontrola dostępu.
- Zbyt szerokie udostępnianie: klinika, która otrzymała zgodę na „wszystko” na rok; zakresy i czasy trwania z rozsądnymi domyślnymi ustawieniami.
- Aplikacje z SDK reklamowymi: brak zewnętrznych trackerów w czymkolwiek, co przetwarza dane medyczne.
- Wstrzykiwanie dokumentów do funkcji AI: treść to dane, nigdy instrukcje (RAG na dokumentacji medycznej).
- Długa retencja: dokumentacja przechowywana przez dziesięciolecia; klucze, formaty i zasady dostępu muszą przetrwać personel i dostawców.
W Anpheros
Anpheros stosuje mapę bezpieczeństwa do siebie za pomocą OAuth 2.0 z PKCE dla aplikacji i asymetrycznego uwierzytelniania klienta dla backendów, zgody na cel i czas trwania jako źródła dostępu każdej kliniki, logu dostępu do każdego rekordu w aplikacji danej osoby, szyfrowania danych w spoczynku i w tranzycie, hostingu w UE, braku SDK reklamowych oraz ISMS zgodnego z ISO 27001 i 27799.
Anpheros stosuje tę mapę do siebie: OAuth 2.0 z PKCE dla aplikacji i asymetryczne uwierzytelnianie klienta dla backendów; zgoda na cel i czas trwania jako źródło dostępu każdej kliniki, z możliwością cofnięcia i bez cichego dostępu w nagłych wypadkach; log dostępu do każdego rekordu w aplikacji danej osoby; szyfrowanie w spoczynku i w tranzycie, hosting w UE, brak SDK reklamowych; ISMS zgodny z ISO 27001 z kontrolkami zdrowotnymi ISO 27799. Witryna dla deweloperów dokumentuje uwierzytelnianie, zgodę i bezpieczeństwo.
Powiązane strony
- Wyjaśnienie SMART App Launch
- Platforma zgody pacjenta
- Kto przeglądał moją dokumentację medyczną?
- Wyjaśnienie SMART Health Links
- ISO 27001 vs ISO 27799
- NIS2 dla szpitali i dostawców technologii medycznych
- Bezpieczeństwo platformy (witryna dla deweloperów)
- Uwierzytelnianie (witryna dla deweloperów)
Źródła
- HL7 SMART App Launch
- IETF: OAuth 2.1 (draft)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Wytyczne dotyczące zakupu cyberbezpieczeństwa w szpitalach
Najczęstsze pytania
Czy OAuth 2.1 różni się od 2.0?
OAuth 2.1 konsoliduje 2.0 z najlepszymi praktykami bezpieczeństwa: PKCE jest wymagane dla wszystkich klientów, granty typu implicit i password zostały usunięte, adresy URI przekierowania muszą być dokładnie dopasowane, a tokeny odświeżania dla klientów publicznych muszą być powiązane lub rotowane. SMART on FHIR v2 już tego wymaga w większości.
Co to jest „break-the-glass”?
Dostęp awaryjny do dokumentacji bez wcześniejszej zgody pacjenta, przez lekarza, który podaje uzasadnienie. Musi być to rzadkie, rejestrowane, przeglądane i zgłaszane pacjentowi; nigdy nie jest to domyślna ścieżka dostępu.
Dlaczego pacjenci powinni widzieć log dostępu?
Ponieważ jest to najsilniejszy środek odstraszający przed nieodpowiednim dostępem i najjaśniejsze wyrażenie kontroli: osoba widzi, która klinika co i kiedy odczytała, i może cofnąć zgodę. ISO 27799 i EHDS wskazują w tym samym kierunku.
Czy potrzebuję oddzielnego systemu audytu?
Potrzebujesz logu audytu tylko do odczytu (FHIR AuditEvent lub odpowiednik), którego aplikacja nie może zmienić, przechowywanego zgodnie z polityką, oraz widoku dla pacjenta pochodzącego z tego logu. To, czy jest to oddzielny system, czy zabezpieczone repozytorium w ramach platformy, jest wyborem implementacyjnym.
Wypróbuj za darmo w sandboksie
Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.
Za darmo · 30 syntetycznych pacjentów · bez karty
Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.
O Anpheros →