# Sécurité, confidentialité et résidence des données

> Comment les données des patients sont protégées : résidence des données dans l'UE, isolation des projets, identifiants par paire, identifiants, consentement, provenance, audit visible par le patient, et les limites de la bêta privée.

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

Les données médicales sont les données les plus sensibles qu'une application puisse détenir. Cette page liste la manière dont la plateforme Anpheros les protège aujourd'hui — uniquement ce qui est implémenté — et ce qui reste limité pendant la bêta privée.

## Résidence des données

- Toutes les données de la plateforme sont stockées et traitées dans l'Union Européenne : le service et ses bases de données dans Google Cloud `europe-west4` (Pays-Bas), la file d'attente de livraison des webhooks dans `europe-west3` (Francfort) et l'exportation immuable du journal d'accès dans l'emplacement UE de BigQuery.
- **Région de données US :** disponible sur demande pour les clients en production sous un accord de partenaire commercial HIPAA (voir ci-dessous) ; les données des patients US ne quittent alors jamais la région US.
- Les documents sont stockés dans un bucket de stockage UE chiffré avec une clé de chiffrement gérée par le client (CMEK). Les originaux sont immuables après finalisation ; leur somme de contrôle SHA-256 et leur taille sont enregistrées.

## Isolation entre les applications

- Chaque clé d'API appartient à un **projet**. Un projet ne voit que les patients qu'il a créés — dans le bac à sable (sandbox), y compris sa propre copie de patients synthétiques, que aucun autre projet ne peut voir.
- **Identifiants par paire :** chaque projet reçoit son propre identifiant pour la même personne ; les identifiants internes ne quittent jamais la plateforme, de sorte que les identifiants ne peuvent pas être corrélés entre les applications.
- Un enregistrement que vous ne pouvez pas atteindre répond `404`, jamais `403`, de sorte que l'existence d'un patient ne peut pas être sondée.
- **Le bac à sable (sandbox) et la production sont des bases de données séparées.** Une clé de bac à sable (sandbox) (`sk_test_`) ne peut physiquement pas accéder aux patients réels.
- Avec le consentement du patient, une organisation lit l'intégralité de l'enregistrement, y compris ce que d'autres organisations ont écrit, mais ne peut modifier ou supprimer que ce qu'elle a écrit elle-même.

## Identifiants

- Les clés d'API sont affichées une seule fois et stockées uniquement sous forme de hachage SHA-256. Les clés ont `read` / `write` scopes et ne traversent jamais leur environnement.
- OAuth 2.1 avec PKCE obligatoire (S256) ; le `redirect_uri` doit être enregistré exactement. Les jetons d'accès durent 30 minutes, les jetons de rafraîchissement 30 jours et pivotent à chaque utilisation.
- **Détection de réutilisation de jeton de rafraîchissement :** la présentation d'un jeton de rafraîchissement déjà utilisé révoque toute la chaîne de jetons.
- Les réponses de jeton transportent `Cache-Control: no-store`. Les `id_token` OpenID Connect sont signés avec RS256 ; les clés publiques sont publiées à l'adresse `/oauth/jwks`.

## Consentement, provenance et audit

- Un patient accorde à une application l'accès sur une page de consentement hébergée, en choisissant l'enregistrement et la durée (30, 90, 180 ou 365 jours). Les scopes sont par type de ressource et par action, optionnellement filtrés par catégorie. Chaque autorisation est répliquée sous forme de ressource FHIR `Consent`.
- La révocation prend effet à la prochaine requête ; l'application ne peut pas se reconnecter.
- **Chaque écriture** produit une ressource `Provenance` : qui l'a écrite (patient, praticien, appareil, importation ou IA), pour quelle organisation, depuis quel système source.
- **Chaque lecture est enregistrée et visible par le patient**, y compris les lectures effectuées avec la clé API du projet, et y compris le contexte construit pour les modèles d'IA.

## Sécurité du transport et du web

- HTTPS uniquement, avec HTTP Strict Transport Security. Les réponses de l'API incluent une Content-Security-Policy restrictive, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` et une politique de référent stricte.
- Les livraisons de webhooks sont signées avec HMAC-SHA256 sur l'horodatage et le corps ; les récepteurs doivent rejeter les signatures plus anciennes que 5 minutes. Les événements portent des identifiants et des versions, jamais de contenu clinique.
- Limites de débit : 600 requêtes par minute par identifiants et par IP ; corps JSON jusqu'à 2 MiB ; documents jusqu'à 25 MiB.

## Moteurs de recherche et robots d'exploration IA

Les pages publiques (anpheros.com, la présentation de la plateforme et cette documentation) sont ouvertes aux moteurs de recherche et aux robots d'exploration IA. L'API, le tableau de bord, les pages OAuth et de consentement, ainsi que l'application patient (`app.anpheros.com`) sont exclus avec les règles `noindex` et `robots.txt` ; aucune d'entre elles ne renvoie de données patient sans authentification.

## HIPAA (cliniques américaines)

Pour une clinique aux États-Unis, Anpheros est un **Business Associate**. Ce qui est en place, mappé à la HIPAA Security Rule :

| Safeguard | Comment Anpheros le fait |
|---|---|
| Responsabilité assignée, analyse des risques, politiques écrites (§164.308) | Un responsable de la sécurité nommé ; une analyse des risques annuelle ; dix politiques écrites (accès, chiffrement, journalisation, réponse aux incidents, notification de violation, conservation et sauvegarde, formation, appareils, accès d'urgence, fournisseurs), conservées six ans |
| Identification unique de l'utilisateur, contrôle d'accès (§164.312(a)) | Chaque clé, jeton et personne a sa propre identité ; les projets ne voient que leurs propres patients ; les scopes de consentement appliqués à chaque lecture ; MFA ou SSO requis pour les organisations ayant un projet de production ; déconnexion automatique sur le tableau de bord |
| Contrôles d'audit (§164.312(b)) | Chaque lecture et écriture journalisée, chaînée par hachage, exportée en mode append-only ; visible par le patient |
| Intégrité (§164.312(c)) | Ressources versionnées, provenance sur chaque écriture, documents immuables avec SHA-256 |
| Sécurité de la transmission (§164.312(e)) | TLS 1.2+, HSTS, webhooks signés, livraisons HTTPS uniquement |
| Chiffrement au repos | Base de données et sauvegardes chiffrées ; documents sous une clé gérée par le client |
| Plan de contingence (§164.308(a)(7)) | Sauvegardes quotidiennes, récupération à un point précis dans le temps, exercice de restauration tous les 90 jours avec horaires enregistrés |
| Notification de violation (§164.410) | L'Entité Couverte est notifiée dans les 5 jours ouvrables par notre BAA (60 jours par la loi) |
| Chaîne de sous-traitants (§164.308(b)) | Google Cloud sous son BAA ; la liste des sous-traitants est dans l'annexe du BAA |

Un **Business Associate Agreement** et une **région de données US** sont disponibles sur demande pour les clients en production (écrire à platform@anpheros.com) ; la production pour les données de patients US s'ouvre après la signature du BAA. Le sandbox contient uniquement des patients synthétiques, permettant aux développeurs aux États-Unis de construire dès aujourd'hui sans BAA. Anpheros n'est pas certifié SOC 2 ou HITRUST ; un audit SOC 2 Type II est prévu lorsqu'un client hospitalier l'exigera.

## Limites actuelles (bêta privée)

- Hébergement en zone unique sans basculement automatique ; pas encore de SLA contractuel.
- Les clés de production sont délivrées aux organisations vérifiées avec un accord de traitement des données signé ; les partenaires bêta commencent avec des données synthétiques.
- Le lancement SMART EHR et le paramètre OpenID `nonce` ne sont pas encore pris en charge.

## Liens connexes

- [RGPD et données de santé pour les développeurs](https://developers.anpheros.com/fr/guides/gdpr-health-data-developers)
- [Provenance des données médicales expliquée](https://developers.anpheros.com/fr/guides/medical-data-provenance) : qui a écrit quoi, et comment l'enregistrer
- [Modèle de consentement et d'accès](https://developers.anpheros.com/fr/guides/consent)
- [Authentification et OAuth](https://developers.anpheros.com/fr/guides/authentication)
- [Limites et limitations de débit](https://developers.anpheros.com/fr/guides/limits)
- [Fiabilité, statut et incidents](https://developers.anpheros.com/fr/guides/reliability) : surveillance, sauvegardes, communication d'incidents
- [Architecture](https://developers.anpheros.com/fr/guides/architecture)
- [L'Espace européen des données de santé (EEDS) pour les développeurs](https://developers.anpheros.com/fr/guides/ehds-for-developers)