Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Bezpieczeństwo, prywatność i lokalizacja danych
Jak chronione są dane pacjentów: lokalizacja danych w UE, izolacja projektów, identyfikatory par, poświadczenia, zgody, pochodzenie danych, audyt dostępny dla pacjenta oraz ograniczenia prywatnej bety.
Dane medyczne to najbardziej wrażliwe dane, jakie może przechowywać aplikacja. Ta strona wymienia, w jaki sposób Anpheros Platform chroni je dzisiaj — tylko to, co zostało zaimplementowane — oraz co jest nadal ograniczone podczas prywatnej wersji beta.
Rezydencja danych
- Wszystkie dane platformy są przechowywane i przetwarzane w Unii Europejskiej: usługa i jej bazy danych w Google Cloud
europe-west4(Holandia), kolejka dostarczania webhooków weurope-west3(Frankfurt) oraz zapis eksportu dziennika dostępu w lokalizacji BigQuery w UE. - Region danych w USA: dostępny na żądanie dla klientów produkcyjnych na podstawie umowy o współpracy biznesowej HIPAA (patrz poniżej); dane pacjentów z USA nigdy nie opuszczają regionu USA.
- Dokumenty są przechowywane w zasobniku magazynu UE zaszyfrowanym kluczem szyfrowania zarządzanym przez klienta (CMEK). Oryginały są niezmienne po finalizacji; ich suma kontrolna SHA-256 i rozmiar są rejestrowane.
Izolacja między aplikacjami
- Każdy klucz API należy do jednego projektu. Projekt widzi tylko pacjentów, których sam utworzył — w piaskownicy, w tym własną kopię pacjentów syntetycznych, której żaden inny projekt nie może zobaczyć.
- Identyfikatory parami: każdy projekt otrzymuje własne identyfikatory dla tej samej osoby; identyfikatory wewnętrzne nigdy nie opuszczają platformy, więc identyfikatory nie mogą być korelowane między aplikacjami.
- Rekord, do którego nie można uzyskać dostępu, odpowiada
404, nigdy403, więc istnienie pacjenta nie może być badane. - Piaskownica i produkcja to oddzielne bazy danych. Klucz piaskownicy (
sk_test_) fizycznie nie może uzyskać dostępu do prawdziwych pacjentów. - Za zgodą pacjenta organizacja odczytuje cały rekord, w tym to, co napisały inne organizacje, ale może zmieniać lub usuwać tylko to, co sama napisała.
Poświadczenia
- Klucze API są wyświetlane raz i przechowywane wyłącznie jako skrót SHA-256. Klucze mają zakresy
read/writei nigdy nie przekraczają swojego środowiska. - OAuth 2.1 z obowiązkowym PKCE (S256);
redirect_urimusi być zarejestrowane dokładnie. Tokeny dostępu są ważne przez 30 minut, tokeny odświeżania przez 30 dni i są rotowane przy każdym użyciu. - Wykrywanie ponownego użycia tokena odświeżania: przedstawienie tokena odświeżania, który został już użyty, powoduje unieważnienie całego łańcucha tokenów.
- Odpowiedzi tokenów zawierają
Cache-Control: no-store. Identyfikatoryid_tokenOpenID Connect są podpisywane algorytmem RS256; klucze publiczne są publikowane pod adresem/oauth/jwks.
Zgoda, pochodzenie i audyt
- Pacjent udziela aplikacji dostępu na hostowanej stronie zgody, wybierając rekord i okres (30, 90, 180 lub 365 dni). Zakresy są per typ zasobu i akcja, opcjonalnie filtrowane według kategorii. Każde udzielenie jest odzwierciedlone jako zasób FHIR
Consent. - Odwołanie zgody wchodzi w życie przy następnym żądaniu; aplikacja nie może odświeżyć dostępu.
- Każde zapisanie generuje zasób
Provenance: kto zapisał (pacjent, praktykujący lekarz, urządzenie, import lub AI), dla jakiej organizacji, z jakiego systemu źródłowego. - Każdy odczyt jest rejestrowany i widoczny dla pacjenta, w tym odczyty dokonane za pomocą klucza API projektu, a także kontekst zbudowany dla modeli AI.
Bezpieczeństwo transportu i sieci
- Tylko HTTPS, z HTTP Strict Transport Security. Odpowiedzi API zawierają restrykcyjną politykę Content-Security-Policy,
X-Content-Type-Options: nosniff,X-Frame-Options: DENYoraz ścisłą politykę referrer. - Dostawy webhooków są podpisywane za pomocą HMAC-SHA256 na podstawie znacznika czasu i treści; odbiorcy powinni odrzucać podpisy starsze niż 5 minut. Zdarzenia zawierają identyfikatory i wersje, nigdy treści kliniczne.
- Limity żądań: 600 żądań na minutę na poświadczenie i na adres IP; ciała JSON do 2 MiB; dokumenty do 25 MiB.
Wyszukiwarki i roboty AI
Publiczne strony (anpheros.com, prezentacja platformy i ta dokumentacja) są otwarte dla wyszukiwarek i robotów AI. API, dashboard, strony OAuth i zgody oraz aplikacja pacjenta (app.anpheros.com) są wykluczone za pomocą reguł noindex i robots.txt; żadna z nich nie zwraca danych pacjenta bez uwierzytelnienia.
HIPAA (kliniki w USA)
Dla kliniki w Stanach Zjednoczonych, Anpheros jest Partnerem Biznesowym (Business Associate). Poniżej przedstawiono, w jaki sposób jest to realizowane zgodnie z Zasadą Bezpieczeństwa HIPAA (HIPAA Security Rule):
| Zabezpieczenie | Jak Anpheros to realizuje |
|---|---|
| Przypisana odpowiedzialność, analiza ryzyka, pisemne polityki (§164.308) | Wyznaczony Oficer ds. Bezpieczeństwa; coroczna analiza ryzyka; dziesięć pisemnych polityk (dostęp, szyfrowanie, logowanie, reagowanie na incydenty, powiadamianie o naruszeniach, retencja i kopie zapasowe, szkolenia, urządzenia, dostęp awaryjny, dostawcy), przechowywane przez sześć lat |
| Unikalna identyfikacja użytkownika, kontrola dostępu (§164.312(a)) | Każdy klucz, token i osoba ma swoją własną tożsamość; projekty widzą tylko swoich pacjentów; zakresy zgód egzekwowane przy każdym odczycie; MFA lub SSO wymagane dla organizacji z projektem produkcyjnym; automatyczne wylogowanie z panelu |
| Kontrole audytu (§164.312(b)) | Każdy odczyt i zapis jest logowany, haszowany, eksportowany w sposób append-only; widoczne dla pacjenta |
| Integralność (§164.312(c)) | Zasoby wersjonowane, proweniencja przy każdym zapisie, niezmienne dokumenty z SHA-256 |
| Bezpieczeństwo transmisji (§164.312(e)) | TLS 1.2+, HSTS, podpisane webhooki, dostawy wyłącznie przez HTTPS |
| Szyfrowanie danych w spoczynku | Zaszyfrowana baza danych i kopie zapasowe; dokumenty pod kluczem zarządzanym przez klienta |
| Plan ciągłości działania (§164.308(a)(7)) | Codzienne kopie zapasowe, odzyskiwanie punktowe, ćwiczenia przywracania co 90 dni z zarejestrowanymi czasami |
| Powiadomienie o naruszeniu (§164.410) | Podmiot objęty umową (Covered Entity) jest powiadamiany w ciągu 5 dni roboczych przez nasz BAA (60 dni zgodnie z prawem) |
| Łańcuch partnerów biznesowych (§164.308(b)) | Google Cloud na mocy swojej umowy BAA; lista podwykonawców znajduje się w załączniku do BAA |
Umowa o Partnerstwie Biznesowym (Business Associate Agreement) i region danych w USA są dostępne na życzenie dla klientów produkcyjnych (pisz na [email protected]); produkcja dla danych pacjentów z USA rozpoczyna się po podpisaniu BAA. Środowisko sandbox zawiera wyłącznie syntetycznych pacjentów, dzięki czemu deweloperzy w USA mogą pracować już dziś bez BAA. Anpheros nie posiada certyfikatów SOC 2 ani HITRUST; audyt SOC 2 Type II jest planowany, gdy będzie tego wymagał klient szpitalny.
Aktualne limity (wersja prywatna beta)
- Hosting w jednej strefie bez automatycznego przełączania awaryjnego; brak jeszcze umownego SLA.
- Klucze produkcyjne są wydawane zweryfikowanym organizacjom z podpisaną umową o przetwarzaniu danych; partnerzy beta zaczynają od danych syntetycznych.
- Uruchomienie SMART EHR i parametr OpenID
noncenie są jeszcze obsługiwane.
Powiązane
- RODO a dane medyczne dla deweloperów
- Pochodzenie danych medycznych – wyjaśnienie: kto co napisał i jak to zarejestrować
- Model zgody i dostępu
- Uwierzytelnianie i OAuth
- Limity i limity żądań
- Niezawodność, status i incydenty: monitorowanie, kopie zapasowe, komunikacja w przypadku incydentów
- Architektura
- Europejska Przestrzeń Danych Zdrowotnych (EHDS) dla deweloperów
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card