Entrazure
Trois contraintes propres au secteur
Le renseignement de santé ne tolère aucune ambiguïté. Chaque endroit où une donnée de patient atterrit doit être connu, segmenté, chiffré et journalisé. « On pense qu’elle n’est que dans la base principale » précède un avis d’incident.
Ce sont vos clients qui vous auditent. Le blocage vient rarement du régulateur, mais du premier établissement ou assureur qui envoie un questionnaire de sécurité de deux cents lignes. C’est un document d’architecture déguisé, et y répondre bien est un événement de revenu.
Le temps clinique est la ressource la plus rare. Tout ce qui ajoute une étape à la journée d’une infirmière meurt en un mois. La contrainte n’est pas la précision, c’est le nombre de clics.
Ce que nous construisons ici
- Des landing zones prêtes pour la santé. Renseignements de santé isolés dans leur frontière d’abonnement, chiffrement et diagnostics par politique, points de terminaison privés, revues d’accès planifiées. La landing zone Azure vous est livrée en Terraform.
- Une preuve d’audit produite par le pipeline. Accès, changements et déploiements enregistrés quand ils surviennent, exportables par contrôle : c’est l’architecture de conformité.
- Une identité conçue pour la première question de l’auditeur. Entra ID, accès conditionnel et Privileged Identity Management, pour que l’administration permanente cesse d’exister : cybersécurité et Entra ID.
- De l’IA ancrée sur les données cliniques. Recherche filtrée par les permissions du dossier, inférence dans votre locataire, journalisation complète, frontière explicite sur ce que le système peut faire : ingénierie IA.
- L’intégration clinique. Dossier patient, rendez-vous et facturation reliés par API et événements, pas par des transferts nocturnes non surveillés.
Scénario anonymisé
Scénario anonymisé, pas un client nommé.
Une organisation de soins multisite veut un assistant qui répond aux questions du personnel à partir de sa documentation. Le modèle est facile. Le mandat se joue ailleurs : quels documents remontent à quel rôle, comment les permissions du dossier se propagent dans la recherche, où s’exécute l’inférence, ce qui est journalisé, ce que l’assistant a l’interdiction de faire, et comment un clinicien voit d’où sort une réponse. C’est ce travail qui le rend déployable, pas démontrable.
Le contexte réglementaire que nous prenons comme contrainte
Au Québec, la Loi 25, l’évaluation des facteurs relatifs à la vie privée avant toute communication hors Québec, la Commission d’accès à l’information et les lois provinciales sur les renseignements de santé. Puis HIPAA et SOC 2 Type II, le RGPD pour des données européennes. La résidence est imposée au niveau du groupe d’administration : un nouvel abonnement ne peut pas placer des données de patients dans la mauvaise région.
Questions fréquentes
Azure peut-il être conforme à HIPAA ?
Azure peut être configuré pour soutenir la conformité HIPAA, et Microsoft signe une entente de partenaire commercial couvrant les services visés. Mais la conformité n’est pas une propriété de la plateforme : c’est une propriété de votre configuration. Quels services vous utilisez, comment les renseignements de santé sont segmentés, chiffrés et journalisés, et qui peut les atteindre.
Nous sommes une jeune entreprise de santé numérique. Est-ce surdimensionné pour nous ?
L’exigence suit la donnée, pas l’effectif. Une entreprise de dix personnes qui détient des renseignements de santé porte la même exposition réglementaire qu’un établissement, avec moins de capacité à absorber un incident. Nous ajustons l’architecture à la taille de l’organisation, jamais les contrôles.
Notre premier client institutionnel exige SOC 2. Par où commencer ?
Par l’architecture, pas par le questionnaire. L’essentiel d’un audit SOC 2 porte sur la maîtrise du changement, l’octroi et la revue des accès, et la preuve que les deux ont eu lieu. Si tout cela est appliqué par Azure Policy et par le pipeline, l’audit devient un exercice de reddition. Si c’est manuel, c’est un projet de neuf mois.
L’IA peut-elle toucher aux données cliniques ?
Avec des frontières explicites. La recherche respecte les permissions que l’utilisateur détient déjà sur le dossier source, l’inférence reste dans votre locataire, chaque requête et chaque réponse sont journalisées, et l’interface est conçue pour que le clinicien demeure responsable de la décision. Ce que le système n’a pas le droit de faire est écrit et appliqué, pas sous-entendu.
Où les renseignements peuvent-ils résider, et comment le prouver ?
La restriction de région est imposée par Azure Policy au niveau du groupe d’administration. Un nouvel abonnement en hérite automatiquement, une tentative de déploiement hors zone autorisée est refusée, et le refus est journalisé. Ce journal est la preuve que demande la Commission d’accès à l’information ou un service des approvisionnements, plutôt qu’une déclaration d’intention.