Confiance et sécurité

Une sécurité de niveau santé, conçue dès le premier jour.

Les dossiers patients sont les données les plus sensibles qu'une clinique détient. Chaque couche de The Clinic — de la ligne de base de données jusqu'au prompt du Copilote — est bâtie sur l'hypothèse qu'une violation est inacceptable.

  • Aligné HIPAA
  • RGPD
  • Aligné ISO 27001
  • Isolation par locataire
Conformité

Chaque cadre que votre équipe de conformité réclame.

Nous faisons correspondre nos contrôles aux cadres contre lesquels les cliniques sont réellement auditées, pas seulement à ceux qui brillent sur un badge.

  • HIPAA

    Nous agissons en qualité de business associate et signons une BAA. Chaque accès aux PHI est consigné dans un journal d'audit en ajout seul que l'application elle-même ne peut pas altérer, conservé dix ans par défaut et configurable par clinique.

  • Critères SOC 2

    Contrôles alignés sur les critères de confiance des services SOC 2 (Trust Services Criteria). Aucun rapport d'audit tiers n'est disponible à ce jour, et nous n'en revendiquons aucun.

  • RGPD

    Bases légales documentées, outils DSR intégrés au produit, DPA signé avec chaque clinique, production hébergée dans l'UE.

  • Aligné ISO 27001

    Système de management de la sécurité de l'information aligné sur les contrôles de l'Annexe A. Non certifié.

  • HITRUST

    Alignement de contrôles cartographié sur le HITRUST CSF v11. Aucune évaluation n'a été réalisée.

  • PCI DSS

    Les données de carte ne touchent jamais notre infrastructure — elles sont tokenisées par notre processeur de paiements. Nous ne détenons aucune attestation PCI en notre nom.

Les quatre piliers

Une défense, superposée à chaque niveau de la pile.

Chiffrement des données

  • Chiffrement AES-256 au repos sur chaque cluster Postgres et magasin d'objets
  • TLS 1.3 en transit avec préchargement HSTS et suites de chiffrement modernes uniquement
  • Chiffrement par enveloppe avec des clés de données par clinique
  • Les médias patients ne sont servis que via des URL signées à durée de vie courte — jamais depuis un bucket public

Contrôle d'accès

  • Permissions par rôle couvrant 11 rôles, appliquées dans chaque route d'API
  • Connexion Google ou e-mail et mot de passe, avec une authentification à deux facteurs (TOTP) que vos administrateurs peuvent imposer pour chaque compte du personnel
  • Des restrictions par utilisateur qui peuvent réduire ce qu'un rôle voit, jamais l'élargir
  • Expiration de session, verrouillage anti-force brute et limitation de débit appliqués côté serveur, pas dans le navigateur

Isolation des locataires

  • Politiques de sécurité au niveau des lignes PostgreSQL appliquées à la couche base de données
  • Contexte de locataire propagé via AsyncLocalStorage à chaque requête
  • Une extension Prisma bloque toute écriture inter-tenants à la couche ORM
  • Autotests de tenancy continus exécutés en CI et à chaque déploiement

Audit et surveillance

  • Chaque lecture et écriture de PHI consignée dans un journal d'audit en ajout seul, appliqué par déclencheur de base de données
  • Rétention par défaut de dix ans, configurable par clinique, avec un plancher de 90 jours que l'application ne peut pas abaisser
  • Update, delete et truncate sont rejetés pour chaque rôle de base de données, y compris celui sous lequel l'application s'exécute
  • Les lectures de PHI sont journalisées à la couche des données plutôt que route par route, si bien que la couverture ne peut pas se dégrader à mesure que des routes sont ajoutées
Architecture

Isolation multi-tenant, vérifiée trois fois.

Chaque requête traverse trois couches d'application indépendantes avant de pouvoir toucher un dossier patient. Un défaut dans l'une est rattrapé par les deux autres.

  • Application. Les claims du JWT résolvent un ID de locataire, stocké dans un contexte AsyncLocalStorage pendant toute la vie de la requête.
  • ORM. Une extension Prisma injecte le filtre de locataire à chaque lecture et bloque toute écriture inter-tenants à la couche ORM.
  • Base de données. La sécurité au niveau des lignes de PostgreSQL fait respecter la même frontière à la couche de stockage — une application déréglée ne peut pas la contourner.
AES-256 au reposTLS 1.3 en transitClés par clinique
Requête du clinicienJWT + clinicId
Middleware d'authentificationCouche 1

Résout le locataire, définit le contexte AsyncLocalStorage

Extension Prisma multi-tenantCouche 2

Injecte WHERE clinicId, bloque les écritures inter-tenants

RLS PostgreSQLCouche 3

Des politiques au niveau des lignes contrôlent chaque SELECT et UPDATE

Données de clinique chiffréesAES-256, clés par locataire

Réponse aux incidents

Un carnet de procédures de réponse aux incidents documenté, une surveillance de la disponibilité et des erreurs, et une analyse des causes racines partagée avec toute clinique dont les données ont été concernées.

Divulgation de vulnérabilités

Nous menons un programme de divulgation coordonnée avec une clause de safe harbor pour les chercheurs de bonne foi, et nous créditons publiquement les rapporteurs.

  • Publié security.txt avec un parcours d'escalade et une clé PGP
  • Crédit public pour le premier signalement d'un problème valide
  • Clause de safe harbor pour la recherche de bonne foi
  • Accusé de réception en un jour ouvré

Questions de sécurité

Ce que les équipes de conformité demandent avant de signer.

Signerez-vous une BAA ?

Oui. The Clinic agit en qualité de business associate et exécute une BAA aux côtés de la DPA. Les contrôles alignés sur HIPAA comprennent un accès par rôle sur chaque route d'API, une authentification à deux facteurs que vos administrateurs peuvent imposer, et un journal d'audit en ajout seul qui enregistre chaque lecture et écriture de PHI.

Êtes-vous certifiés SOC 2 ou ISO 27001 ?

Non, et nous ne le revendiquons pas. Les contrôles sont alignés sur les critères de confiance des services SOC 2, et le système de management de la sécurité de l'information est aligné sur l'Annexe A de l'ISO 27001 — mais aucun rapport d'audit tiers n'existe à ce jour. L'alignement est documenté, afin que votre équipe de conformité puisse l'évaluer directement.

Comment les données d'une clinique sont-elles tenues séparées de celles d'une autre ?

L'isolation par locataire est appliquée de trois façons indépendantes à chaque requête : l'application résout le locataire à partir du jeton de l'utilisateur connecté, une couche d'accès aux données injecte le filtre de locataire et bloque les écritures inter-tenants, et la sécurité au niveau des lignes de PostgreSQL fait respecter la même frontière à la couche de stockage. Des autotests de tenancy s'exécutent également en CI et à chaque déploiement.

Le journal d'audit peut-il être modifié ou supprimé ?

Non. Le journal d'audit est en ajout seul, appliqué par un déclencheur de base de données — update, delete et truncate sont rejetés pour chaque rôle de base de données, y compris celui sous lequel l'application elle-même s'exécute. La rétention est de dix ans par défaut, configurable par clinique, avec un plancher de 90 jours que l'application ne peut pas abaisser.

Comment les données patients sont-elles chiffrées ?

AES-256 au repos sur chaque cluster de base de données et magasin d'objets, et TLS 1.3 en transit. Le chiffrement utilise un chiffrement par enveloppe avec une clé de données par clinique, et les médias patients ne sont servis que via des URL signées à durée de vie courte — jamais depuis un bucket public.

Prêt à essayer The Clinic

Voyez-le piloter votre clinique en 30 minutes.

Réservez une démo personnalisée. Nous utiliserons les véritables flux de travail de votre clinique — pas une visite générique.

Aucune carte bancaire. Aucune diapositive. 30 minutes.