# Безпека, конфіденційність та розташування даних

> Як захищені дані пацієнтів: розташування даних в ЄС, ізоляція проєктів, парні ідентифікатори, облікові дані, згода, походження, аудит, видимий пацієнту, та обмеження закритого бета-тестування.

Source: https://developers.anpheros.com/uk/guides/security

Медичні дані є найбільш чутливими даними, які може зберігати застосунок. Ця сторінка перелічує, як Anpheros Platform захищає їх сьогодні — лише те, що реалізовано — та що ще обмежено під час закритого бета-тестування.

## Розташування даних

- Усі дані платформи зберігаються та обробляються в Європейському Союзі: сервіс та його бази даних у Google Cloud `europe-west4` (Нідерланди), черга доставки вебхуків у `europe-west3` (Франкфурт) та незмінний експорт журналу доступу в локації BigQuery EU.
- **Регіон даних США:** доступний за запитом для виробничих клієнтів відповідно до угоди про ділових партнерів HIPAA (див. нижче); дані пацієнтів США тоді ніколи не залишають регіон США.
- Документи зберігаються у сховищі EU, зашифрованому ключем шифрування, керованим клієнтом (CMEK). Оригінали є незмінними після завершення; їх контрольна сума SHA-256 та розмір записуються.

## Ізоляція між додатками

- Кожен API-ключ належить одному **проєкту**. Проєкт бачить лише пацієнтів, яких він створив — у пісочниці, включаючи власну копію синтетичних пацієнтів, яку жоден інший проєкт не може бачити.
- **Парні ідентифікатори:** кожен проєкт отримує власний ідентифікатор для однієї й тієї ж особи; внутрішні ідентифікатори ніколи не залишають платформу, тому ідентифікатори не можуть бути корельовані між додатками.
- Запис, до якого ви не можете отримати доступ, відповідає `404`, ніколи `403`, тому існування пацієнта не може бути перевірено.
- **Пісочниця та продакшн — це окремі бази даних.** Ключ пісочниці (`sk_test_`) фізично не може отримати доступ до реальних пацієнтів.
- За згодою пацієнта організація читає весь запис, включаючи те, що написали інші організації, але може змінювати або видаляти лише те, що написала сама.

## Облікові дані

- Ключі API відображаються один раз і зберігаються лише як хеш SHA-256. Ключі мають `read` / `write` областей дії (scopes) і ніколи не виходять за межі свого середовища.
- OAuth 2.1 з обов'язковим PKCE (S256); `redirect_uri` має бути зареєстровано точно. Токени доступу діють 30 хвилин, токени оновлення – 30 днів і обертаються при кожному використанні.
- **Виявлення повторного використання токена оновлення:** пред'явлення токена оновлення, який вже був використаний, анулює весь ланцюжок токенів.
- Відповіді токенів містять `Cache-Control: no-store`. Токени OpenID Connect `id_token` підписуються за допомогою RS256; публічні ключі опубліковані за адресою `/oauth/jwks`.

## Згода, походження та аудит

- Пацієнт надає додатку доступ на розміщеній сторінці згоди, обираючи запис та тривалість (30, 90, 180 або 365 днів). Області дії (scopes) є для кожного типу ресурсу та дії, опціонально фільтруються за категорією. Кожне надане право відображається як ресурс FHIR `Consent`.
- Відкликання набуває чинності при наступному запиті; додаток не може оновити доступ.
- **Кожен запис (write)** створює ресурс `Provenance`: хто його створив (пацієнт, практикуючий лікар, пристрій, імпорт або ШІ), для якої організації, з якої вихідної системи.
- **Кожне читання (read) реєструється та є видимим для пацієнта**, включаючи читання, зроблені за допомогою власного ключа API проєкту, та включаючи контекст, створений для моделей ШІ.

## Транспорт та веб-безпека

- Тільки HTTPS, з HTTP Strict Transport Security. Відповіді API містять обмежувальну політику Content-Security-Policy, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` та сувору політику referrer.
- Доставлення вебхуків підписується за допомогою HMAC-SHA256 з використанням часової мітки та тіла; отримувачі повинні відхиляти підписи, старші за 5 хвилин. Події містять ідентифікатори та версії, але ніколи клінічний вміст.
- Обмеження швидкості: 600 запитів на хвилину на облікові дані та на IP; тіла JSON до 2 MiB; документи до 25 MiB.

## Пошукові системи та AI-краулери

Публічні сторінки (anpheros.com, презентація платформи та ця документація) відкриті для пошукових систем та AI-краулерів. API, панель керування, сторінки OAuth та згоди, а також додаток для пацієнтів (`app.anpheros.com`) виключені правилами `noindex` та `robots.txt`; жоден з них не повертає дані пацієнта без автентифікації.

## HIPAA (Клініки США)

Для клініки в Сполучених Штатах Anpheros є **Діловим партнером**. Ось що впроваджено, відповідно до Правила безпеки HIPAA:

| Заходи безпеки | Як це робить Anpheros |
|---|---|
| Призначення відповідальності, аналіз ризиків, письмові політики (§164.308) | Призначений офіцер з безпеки; щорічний аналіз ризиків; десять письмових політик (доступ, шифрування, журналювання, реагування на інциденти, сповіщення про порушення, зберігання та резервне копіювання, навчання, пристрої, екстрений доступ, постачальники), що зберігаються шість років |
| Унікальна ідентифікація користувача, контроль доступу (§164.312(a)) | Кожен ключ, токен і особа мають власну ідентифікацію; проєкти бачать лише своїх пацієнтів; сфери згоди застосовуються до кожного читання; MFA або SSO потрібні для організацій з виробничим проєктом; автоматичний вихід з системи на панелі керування |
| Аудит контролю (§164.312(b)) | Кожне читання та запис журналюється, хешується, експортується тільки для додавання; доступно для пацієнта |
| Цілісність (§164.312(c)) | Версіоновані ресурси, відстеження походження кожного запису, незмінні документи з SHA-256 |
| Безпека передачі (§164.312(e)) | TLS 1.2+, HSTS, підписані вебхуки, доставки тільки через HTTPS |
| Шифрування даних у стані спокою | База даних та резервні копії зашифровані; документи під ключем, керованим клієнтом |
| План дій у надзвичайних ситуаціях (§164.308(a)(7)) | Щоденні резервні копії, відновлення на певний момент часу, перевірка відновлення кожні 90 днів із записаними часами |
| Сповіщення про порушення (§164.410) | Покрита сутність сповіщається протягом 5 робочих днів нашим BAA (60 днів за законом) |
| Ланцюжок ділових партнерів (§164.308(b)) | Google Cloud за його BAA; список субпідрядників знаходиться в додатку до BAA |

**Угода про ділове партнерство** та **регіон даних США** доступні за запитом для виробничих клієнтів (пишіть на platform@anpheros.com); виробництво для даних пацієнтів США відкривається після підписання BAA. Пісочниця містить лише синтетичних пацієнтів, тому розробники в США можуть працювати вже сьогодні без BAA. Anpheros не сертифікований за SOC 2 або HITRUST; аудит SOC 2 Type II заплановано, коли цього вимагатиме клієнт-лікарня.

## Поточні обмеження (закрита бета-версія)

- Однозонний хостинг без автоматичного відмовостійкого переключення; договір SLA ще не укладено.
- Ключі для виробничого середовища видаються перевіреним організаціям з підписаною угодою про обробку даних; бета-партнери починають з синтетичними даними.
- Запуск SMART EHR та параметр OpenID `nonce` наразі не підтримуються.

## Пов'язане

- [GDPR та медичні дані для розробників](https://developers.anpheros.com/uk/guides/gdpr-health-data-developers)
- [Пояснення походження медичних даних](https://developers.anpheros.com/uk/guides/medical-data-provenance): хто що написав і як це записати
- [Модель згоди та доступу](https://developers.anpheros.com/uk/guides/consent)
- [Автентифікація та OAuth](https://developers.anpheros.com/uk/guides/authentication)
- [Обмеження та ліміти запитів](https://developers.anpheros.com/uk/guides/limits)
- [Надійність, статус та інциденти](https://developers.anpheros.com/uk/guides/reliability): моніторинг, резервне копіювання, комунікація щодо інцидентів
- [Архітектура](https://developers.anpheros.com/uk/guides/architecture)
- [Європейський простір даних охорони здоров'я (EHDS) для розробників](https://developers.anpheros.com/uk/guides/ehds-for-developers)