Zbudowaliśmy dwie produkcyjne platformy mental health w obu tych reżimach. Mentalyc – narzędzie AI do dokumentacji terapeutycznej działające pod HIPAA i SOC 2 Type II w USA. Selfapy – platforma terapeutyczna CBT z certyfikacją BSI IT-Grundschutz w Niemczech, z ponad 120 spełnionymi wymaganiami bezpieczeństwa przed launchem.
Oto co budowanie pod oba reżimy oznacza w praktyce.
Czym jest HIPAA i co wymaga od zespołu inżynierskiego?
HIPAA to amerykańskie prawo federalne regulujące ochronę danych zdrowotnych pacjentów (PHI). Dla platformy mental health PHI to nagrania sesji, notatki terapeutyczne, diagnozy- każda dana łącząca pacjenta z jego stanem zdrowia. HIPAA nie jest certyfikatem. To ciągłe wymaganie operacyjne bez daty ważności.
Architektonicznie oznacza cztery rzeczy, których nie można dodać po fakcie:
- Szyfrowanie PHI w spoczynku i w tranzycie na każdej granicy danych i API
- Kontrola dostępu na poziomie domeny, nie tylko warstwy aplikacji
- Audit logging każdego dostępu do PHI z detalem wystarczającym do rekonstrukcji śledczej
- Business Associate Agreement z każdym zewnętrznym dostawcą, którego system dotyka PHI
Schema bazy danych, konfiguracja logowania, struktura odpowiedzi API zbudowane bez separacji PHI nie nadają się do patchowania. Wymagają przebudowy.
W praktyce oznacza to, że audytor HIPAA pyta nie „czy macie szyfrowanie” ale „pokaż mi log każdego dostępu do tego rekordu pacjenta z ostatnich 6 miesięcy”. Zespoły które dodały logowanie po fakcie, na bazie architektury która tego nie przewidywała, nie są w stanie odpowiedzieć na to pytanie bez tygodni pracy wstecznej.
Czym jest BSI IT-Grundschutz i czym różni się od HIPAA?
BSI IT-Grundschutz to standard bezpieczeństwa opublikowany przez Federalny Urząd ds. Bezpieczeństwa Informacji w Niemczech. W odróżnieniu od HIPAA, który jest regulacją prawną ,BSI to formalny standard techniczny z audytowalnymi wymaganiami, akredytowanymi certyfikatorami i cyklami odnowień.
Certyfikacja BSI nie jest prawnym obowiązkiem w Niemczech w takim sensie jak HIPAA w USA. Niemieccy inwestorzy, kasy chorych i partnerzy instytucjonalni traktują jednak jej brak jako dyskwalifikator.
Dla Selfapy certyfikacja oznaczała spełnienie ponad 120 indywidualnych wymagań obejmujących bezpieczeństwo aplikacji, infrastrukturę, reakcję na incydenty i dokumentację. Każde wymaganie jest konkretne i audytowalne.
Proces ma określony rytm: analiza luk, remediacja, audyt, certyfikacja, odnowienie. Dla PM-a planującego roadmapę oznacza to konkretną konsekwencję: każdy release dotykający komponentów bezpieczeństwa musi być zaplanowany z wyprzedzeniem wystarczającym na przejście przez cykl certyfikacyjny. Zespół który odkrywa to w połowie kwartału, przesuwając release o sześć tygodni — odkrywa to za późno. W projekcie Selfapy rytm certyfikacyjny był elementem planowania sprintów od pierwszego dnia współpracy, nie osobnym procesem obok developmentu.
„Bezpieczeństwo w projektach healthcare musi być wbudowane od pierwszego dnia, nie dodawane przed audytem.” – Gosia Tańska, Mobile Developer, fireup.pro, lead projektu Selfapy
HIPAA, BSI i GDPR: co każdy framework wymaga od architektury
Platforma działająca w USA i w Niemczech musi spełniać wszystkie trzy reżimy jednocześnie. Architektura bezpieczeństwa pokrywa się — ale zobowiązania prawne, standardy dokumentacji i wymagania dotyczące lokalizacji danych już nie.
| HIPAA (US) | BSI IT-Grundschutz (DE) | GDPR (EU) | |
|---|---|---|---|
| Typ | Regulacja prawna | Standard techniczny | Rozporządzenie o ochronie danych |
| Certyfikacja | Brak — audit-based | Formalna certyfikacja z odnowieniem | Brak – ciągła zgodność |
| Rytm | Ciągłe wymaganie operacyjne | Ustrukturyzowany proces z deadline’ami | Ciągłe, z obowiązkiem powiadamiania o naruszeniach |
| Kontrakty z dostawcami | BAA z każdym dostawcą dotykającym PHI | Kontrole łańcucha dostaw | Data Processing Agreements (DPA) |
| Kluczowe wymagania architektoniczne | Szyfrowanie, RBAC, audit logi, izolacja PHI | 120+ kontroli technicznych, pen testy, dokumentacja | Minimalizacja danych, prawo do usunięcia, przenoszalność |
GDPR obejmuje dane osobowe wszystkich rezydentów UE niezależnie od siedziby platformy. Platforma budowana najpierw pod USA, rozszerzana na Niemcy, musi nałożyć wymagania GDPR i BSI na istniejącą architekturę HIPAA. Kompatybilność tych warstw wymaga świadomego projektowania — nie założenia, że sama się ułoży.
HIPAA a funkcje AI w platformie mental health
Funkcje AI w platformie mental health są wewnątrz perimetru compliance, nie poza nim.
W Mentalyc każde nagranie, transkrypt i wygenerowana przez AI notatka to PHI. Pipeline AI podlega tym samym wymaganiom szyfrowania, kontroli dostępu i audit logowania co reszta systemu.
Konkretne wyzwanie: automatyzacja testów. Przy typowej aplikacji CRUD izolacja środowiska testowego od danych produkcyjnych jest standardowym krokiem – mock data zastępuje prawdziwe rekordy. Przy funkcjach opartych na audio AI to nie działa. Model musi przetworzyć prawdziwe nagranie żeby wyprodukować realistyczny output a każde prawdziwe nagranie sesji terapeutycznej to PHI. Środowisko testowe które dotknęłoby produkcyjnych nagrań, złamałoby HIPAA. Środowisko które używa wyłącznie syntetycznych danych, nie testuje tego co ważne.
Rozwiązaniem był framework oparty na Playwright, Cucumber BDD i konteneryzacji Docker. Testy działają w izolowanych środowiskach bez dostępu do produkcyjnego PHI, z zestawem starannie przygotowanych anonimizowanych nagrań testowych które zachowują cechy akustyczne prawdziwych sesji. Warstwa BDD dała niestechnicznym stakeholderom Mentalyc wgląd w to co dokładnie jest testowane i na jakich warunkach, istotne kiedy audytorzy SOC 2 Type II pytają o procedury testowe.
Wynik: czas testowania skrócony z kilku godzin do 24–25 minut. Zespół zyskał powtarzalny, audytowalny proces testowy, w regulowanym środowisku równie ważny co szybkość.
EU AI Act a platformy mental health w Europie
Narzędzia AI wpływające na decyzje kliniczne muszą być projektowane pod wymagania high-risk EU AI Act od pierwszego sprintu.
Annex III EU AI Act obejmuje systemy AI w ochronie zdrowia wspierające lub wpływające na decyzje kliniczne. Klasyfikacja high-risk wymaga oceny zgodności, dokumentacji technicznej, mechanizmów nadzoru ludzkiego i rejestracji w unijnej bazie danych.
„Human oversight mechanism” brzmi abstrakcyjnie, w kodzie oznacza konkretne rzeczy. Każda decyzja lub rekomendacja AI musi być możliwa do zablokowania lub nadpisania przez człowieka przed tym jak wpłynie na rekord pacjenta. System musi logować nie tylko output modelu, ale też to czy i jak terapeuta go zmodyfikował. Musi być możliwe odtworzenie pełnej historii: co model zaproponował, co człowiek zmienił, co trafiło do dokumentacji. To są wymagania na poziomie schematu bazy danych i projektu API, nie funkcjonalność którą można dodać jako kolejny endpoint po launchu.
Dla zespołów budujących w Niemczech dochodzi potencjalna klasyfikacja jako SaMD (Software as a Medical Device) pod MDR 2017/745 z wymaganiami oznakowania CE i osobną oceną zgodności. Połączenie klasyfikacji MDR SaMD, GDPR Article 9, BSI IT-Grundschutz i EU AI Act high-risk to compliance stack przez który przechodzą poważne produkty digital health w Niemczech w 2025 i 2026 roku.
Jak długo trwa budowa platformy mental health zgodnej z HIPAA?
Przy właściwych decyzjach architektonicznych podjętych na początku – 4 miesiące do produkcji.
Taki był timeline dla 9am.health – wirtualnej kliniki zbudowanej przez nasz zespół od pierwszej linii kodu w 2021 roku. Platforma obsługuje dziś pracowników Amazon, Novo Nordisk i State of Georgia, a w samym 2026 roku przybyło przez nią 40 000 nowych użytkowników z programów benefitów pracodawców.
Zespoły odkładające izolację PHI na później, mockujące weryfikację eligibility lub traktujące compliance jako osobny workstream nie dostarczają szybciej. Dostarczają, odkrywają luki i spędzają następny kwartał na przebudowie.
Podsumowanie
Cztery reżimy compliance, dwa rynki, jedna architektura – to decyzja którą podejmujesz w pierwszym sprincie albo płacisz za nią przebudową kilka miesięcy później.
Z naszego doświadczenia przy Mentalyc i Selfapy wynika jedno powtarzające się spostrzeżenie: zespoły które traktują HIPAA, BSI i GDPR jako osobne workstreamy zawsze dochodzą do tego samego miejsca. Systemy które działają, ale których nie można skalować. Funkcje AI które działają w demo, ale nie mogą trafić na produkcję bez naruszenia wymagań. Architektury które przeszły audyt wewnętrzny, ale nie przejdą zewnętrznego.
Platformy mental health obsługują dane wyjątkowo wrażliwe i wyjątkowo regulowane. Błąd architektoniczny w e-commerce kosztuje refaktor. W platformie terapeutycznej kosztuje certyfikację, zaufanie użytkowników i możliwość działania na danym rynku.
Fireup.pro buduje systemy healthcare od 2018 roku – od mySugr z 1,8M użytkowników przejętego przez Roche, przez 9am.health obsługujące pracowników Amazon i State of Georgia, po Mentalyc i Selfapy. Wspólny mianownik każdego z tych projektów: decyzje architektoniczne podjęte na początku determinowały wszystko co przyszło później.
Budujesz platformę mental health i planujesz wejście na rynek europejski lub amerykański? Chętnie porozmawiamy o tym co to konkretnie wymaga od Twojego systemu.
