Gérer des données de santé sensibles avec Rails : les bases de la sécurité et de la conformité pour la HealthTech

Construire une application Rails qui manipule des données de santé change le niveau d'exigence de base, pas seulement la checklist. En France, cela implique les exigences d'hébergement HDS (Hébergement de Données de Santé) ; plus largement, cela signifie traiter certains champs comme catégoriquement différents du reste de votre schéma, et non comme « un peu sensibles ».

Savoir quels champs comptent réellement

Les données de santé au sens du RGPD ne se limitent pas aux champs évidents comme un diagnostic. Un champ qui permet d'inférer un état de santé, un type de rendez-vous, un nom de médicament, voire certaines notes en texte libre, relève des mêmes règles plus strictes. La première étape de toute revue de conformité consiste à cartographier précisément quelles colonnes, dans toutes les tables, présentent ce risque d'inférence, car la plupart des équipes sous-estiment cette liste.

Chiffrer au niveau des champs, pas seulement au repos

Le chiffrement du disque entier ou de la base entière protège contre un disque dur volé ; il ne protège en rien contre un identifiant de base de données compromis ou un réplica en lecture aux droits trop larges. Pour les champs réellement sensibles, nous utilisons le chiffrement d'attributs intégré à Rails, de sorte que la valeur est chiffrée en mémoire applicative avant même d'atteindre un log de requêtes, une sauvegarde ou un réplica.

class PatientRecord < ApplicationRecord
  encrypts :diagnosis_notes, deterministic: false
end

Les accès exigent une piste d'audit, pas seulement une liste de contrôle d'accès

Pour la conformité, qui a le droit de consulter un enregistrement compte moins que qui l'a réellement fait, et quand. Dans les systèmes que nous construisons pour ce secteur, chaque lecture d'un enregistrement sensible, et pas seulement chaque écriture, est journalisée avec l'utilisateur à l'origine de l'action et un code motif, car ce journal est la première chose que demande un auditeur, et c'est le seul moyen fiable de détecter un employé qui consulte des dossiers qu'il n'avait aucune raison légitime d'ouvrir.

L'hébergement est une décision, pas une case à cocher

La certification HDS s'applique à l'hébergeur et à des engagements contractuels et techniques précis, pas au code de votre application. Vérifiez tôt, par écrit, que votre hébergeur détient bien une certification HDS en cours de validité pour les services précis que vous utilisez, car un hébergeur certifié peut tout à fait proposer des services non certifiés, plutôt que de découvrir cet écart lors de la due diligence d'un client.

Rien de tout cela n'est de l'ingénierie exotique. C'est de la discipline appliquée avec constance à un ensemble de champs plus restreint qu'on ne le croit, ce qui explique précisément pourquoi il est facile de n'en faire qu'une partie correctement et dangereux de laisser le reste de côté.