Sécurité et confidentialité des données patient
PLENISHEM applique les meilleures pratiques de sécurité de l'industrie médicale : chiffrement au repos et en transit, contrôle d'accès basé sur les rôles, journal d'audit inviolable et déconnexion automatique.
Document de consentement RGPD
Apres avoir lu la presente politique, telechargez ce document, signez-le, puis deposez-le depuis votre espace : c est lui, et non une case cochee, qui vaut consentement.
Connectez-vous pour telecharger le document🔐 1. Chiffrement au repos (données stockées)
Chaque champ contenant une information nominative sensible (PII) ou clinique
(PHI) est chiffré avant écriture dans la base de données via
l'algorithme AES-256-CBC, en utilisant la clé applicative APP_KEY
(256 bits, stockée hors de la base et hors du dépôt).
Champs chiffrés automatiquement au niveau du modèle Eloquent (via les casts
'encrypted' de Laravel) :
- Patient : numéro de pièce d'identité, téléphone, email, adresse, notes internes
- Encounter (note clinique SOAP) : Subjectif, Objectif, Analyse, Plan
- Prescription : posologie détaillée
- Vitals / Immunizations / Allergies / Problems : notes libres
- Appointment : motif, notes internes
- Message : corps du message
- TeleconsultationSession : compte-rendu
- User : secret TOTP MFA
Concrètement : même une personne obtenant un dump SQL de la base ne verra que du binaire chiffré — impossible de lire un dossier sans la clé applicative.
📄 2. Documents patients — stockage privé chiffré
Les documents attachés (ordonnances scannées, résultats de labo, imagerie) sont stockés sur un
disque phi configuré hors de public/, donc jamais
accessible en direct via URL.
- Nom de fichier aléatoire (
uuid + .enc), pas de nom d'origine sur le disque - Empreinte
SHA-256stockée pour vérifier l'intégrité à chaque téléchargement - Tout accès passe par
DocumentController@downloadqui vérifie l'ACL, journalise l'accès, puis stream le fichier déchiffré à la volée
🌐 3. Chiffrement en transit
- TLS 1.3 forcé (redirection HTTP → HTTPS +
Strict-Transport-Security) - Cookies de session :
Secure,HttpOnly,SameSite=strict, payload chiffré AES-256 (SESSION_ENCRYPT=true) - En-têtes de durcissement :
X-Frame-Options: SAMEORIGIN,X-Content-Type-Options: nosniff,Referrer-Policy: strict-origin-when-cross-origin - Téléconsultation : flux vidéo/audio chiffrés SRTP peer-to-peer — ils ne transitent jamais par nos serveurs. La signalisation SDP passe par HTTPS.
👥 4. Contrôle d'accès basé sur les rôles (RBAC)
Chaque utilisateur a un rôle unique parmi :
super_admin, admin, medecin,
infirmier, secretaire, patient.
Chaque route sensible est gardée par le middleware role:… et une Policy Eloquent
vérifie qu'un utilisateur ne peut voir que les dossiers de son établissement.
Le compte demo@plenisofts.org est en lecture seule (middleware
DemoReadOnly) : toute tentative d'écriture est bloquée.
MFA (authentification à deux facteurs, TOTP) est optionnelle par utilisateur. Le secret est chiffré au repos.
📜 5. Journal d'audit (HIPAA §164.312(b))
Toute action touchant à un dossier patient (PHI) est tracée dans la table audit_logs,
sans possibilité de modification depuis l'interface :
| Action | Déclencheur |
|---|---|
patient.view / phi.access | Ouverture d'un dossier |
patient.create, patient.update | Création / modification du dossier |
encounter.create, encounter.sign | Consultation / signature note SOAP |
prescription.create, prescription.print | Prescription et impression d'ordonnance |
teleconsult.join, teleconsult.patient_view | Participation vidéo + consultation dossier |
auth.login_ok, auth.login_failed, auth.logout | Cycle de vie de la session |
Chaque événement enregistre l'utilisateur, l'IP, le user-agent et
des métadonnées libres. Rétention configurée à 365 jours (channel audit).
⏱️ 6. Déconnexion automatique (HIPAA §164.312(a)(2)(iii))
Après 30 minutes d'inactivité (souris/clavier), la session est automatiquement fermée côté client puis invalidée côté serveur — ce qui évite qu'un poste laissé sans surveillance dans une salle d'examen expose des données patient.
💾 7. Sauvegardes et localisation des données
- Base
SQLitestockée dansdatabase/database.sqlite, hors depublic/, protégée par.htaccess(interdictionDeny from allsur*.sqlite). - Snapshot quotidien de la base et du disque
phi/(rétention 30 j) vers un répertoire hors accès web. - Aucun transit vers un cloud tiers non-EEA — les données restent sur l'infrastructure de l'hébergeur français.
✅ Conformité
L'ensemble des mesures ci-dessus permet à PLENISHEM d'être aligné avec :
- RGPD (Règlement UE 2016/679) — droit à l'information, à l'effacement (soft delete + purge), consentement explicite tracé, journal d'accès
- Loi ivoirienne n°2013-450 sur la protection des données à caractère personnel
- HIPAA Security Rule §164.312 — Access control, audit controls, integrity, transmission security
- Recommandations ANS / HDS (France) pour l'hébergement de données de santé — nécessite en production un hébergeur certifié HDS