Confidentiel dès la conception, selon la LPRPS

Chaque hôpital est un locataire distinct et isolé : EDFlow ne permet jamais à un dépositaire de divulguer des renseignements à un autre. Nous remplissons tout de même volontairement les obligations que la LPRPS impose aux fournisseurs de réseau d'information sur la santé : un résumé écrit de l'évaluation des facteurs relatifs à la vie privée et de la menace et des risques pour chaque hôpital, un journal de chaque accès et transfert offert sur demande, un avis d'atteinte à la première occasion raisonnable et des clauses équivalentes pour les sous-traitants.^[2]

Le moteur d'intégration de l'hôpital réduit les messages aux champs que le contrat nomme avant que quoi que ce soit ne quitte le réseau de l'hôpital, et notre réception refuse toute donnée qui contient des champs interdits.

Les visites terminées restent identifiables pendant une période opérationnelle fixée par l'hôpital (30 jours après le départ par défaut), puis deviennent des données analytiques anonymisées. Les dossiers de soins, comme les demandes urgentes et les avis de délai, suivent le calendrier de conservation des dossiers de santé de l'hôpital. Un profil minimal retire complètement les noms et les dates de naissance du flux.

• Les patients ouvrent leur visite avec le code QR ou le code de leur carte de visite. Les jetons voyagent seulement dans le fragment de l'adresse, sont aléatoires, conservés sous forme de hachages HMAC, limités en fréquence et journalisés à chaque utilisation.
• Les proches voient l'étape, une estimation de l'attente et les prénoms et rôles, seulement si le patient partage, et jamais les examens ni les résultats. Le patient peut révoquer un lien en tout temps.
• Les notifications disent seulement « Vous avez une nouvelle mise à jour. » : aucun hôpital, aucun nom, aucun examen, aucun emplacement, ni sur l'écran verrouillé ni ailleurs.
• Le personnel se connecte avec une authentification à plusieurs facteurs ou l'authentification unique de l'hôpital; ouvrir le dossier d'un patient inscrit l'accès au journal avant la lecture. Les cartes de visite s'impriment seulement aux postes enregistrés, et les écrans du personnel affichent un code masqué, jamais un identifiant utilisable par un patient.

• Résidence. Les établissements hospitaliers fonctionnent sur une infrastructure autohébergée dans AWS ca-central-1 (Montréal), avec ca-west-1 (Calgary) pour la reprise après sinistre; les fonctions serveur fonctionnent dans la région de Montréal de Vercel. Les renseignements sur la santé ne sont jamais générés sur un serveur hors du Canada.^[3]
• Chiffrement. TLS 1.2 ou plus récent avec HSTS en transit; stockage chiffré avec des clés gérées par le client; AES-GCM pour les numéros de téléphone, les secrets d'authentification et les liens en attente.
• Sécurité applicative. Une politique de sécurité du contenu stricte, des témoins limités à l'hôte, une autorisation côté serveur pour chaque fonction avec un accès journalisé pour les lectures du personnel, et des limites de fréquence par réseau, par visite et par site.
• Sauvegardes. Chiffrées, conservées au Canada pendant 35 jours; une restauration applique de nouveau les règles de conservation avant la reprise du service.

• Un test d'intrusion par un tiers avant la première mise en service dans un hôpital, puis chaque année, couvrant le Web, les applications, la réception des données du DME et la matrice d'autorisation.
• Normes de vérification : OWASP ASVS niveau 2 pour le Web et MASVS pour les applications.
• Chaque fonction publique est livrée avec des tests du cas normal, d'un refus d'autorisation et d'une erreur de validation.
• Divulgation responsable : écrivez à security@edflow.space. La recherche de bonne foi qui respecte la politique est bienvenue et protégée. Les détails lisibles par machine sont à /.well-known/security.txt.