Une plateforme conforme HIPAA pour les équipes d'intervention face à la crise des opioïdes

Les équipes d'intervention face aux opioïdes ne disposaient d'aucune solution numérique standardisée pour gérer leurs dossiers et suivre leurs interventions. Beaucoup s'appuyaient sur des tableurs et des documents papier, ce qui limitait leur capacité à mesurer ce qui fonctionne et à améliorer les résultats. Sans systèmes centralisés, les politiques ne pouvaient pas être testées à grande échelle et les données restaient fragmentées d'un comté à l'autre.

Goldie devait centraliser ses workflows critiques dans une plateforme unique et sécurisée, capable de fonctionner de manière fiable en ligne comme hors ligne, de prendre en compte les spécificités régionales et de garantir une conformité totale aux réglementations HIPAA et 42 CFR.

L'équipe Akveo a pris en charge le développement de bout en bout, y compris l'architecture système, le développement backend et frontend, la messagerie en temps réel, la logique de synchronisation mobile hors ligne et le déploiement de l'infrastructure sur AWS, afin de garantir sécurité, conformité et évolutivité.

Conformité HIPAA

Pour garantir la conformité HIPAA, l'application suit ces pratiques clés :

1. Sécurité de la base de données : Architecture multi-tenant : isolation des données de chaque organisation cliente dans des schémas distincts et contrôle d'accès basé sur les rôles. Sauvegardes : mise en place de sauvegardes automatisées et sécurisées.
2. Authentification et contrôle d'accès : Authentification des utilisateurs avec des politiques de mots de passe robustes. Mise en œuvre dans l'application d'un contrôle d'accès basé sur les rôles, selon le principe du moindre privilège.
3. Sécurité de la transmission des données : Chiffrement via HTTPS de toutes les données échangées entre les clients et le serveur.
4. Surveillance et audit : Journalisation des activités pour détecter les opérations suspectes.

Architecture multi-tenant

L'application assure la séparation des données au niveau de chaque entreprise (tenant). Cette séparation empêche les utilisateurs d'un tenant d'accéder aux données d'un autre tenant.

Le tenant auquel appartient un utilisateur est déterminé au moment de l'authentification.

La séparation logique des données est mise en œuvre au niveau de la base de données : une connexion distincte est établie pour chaque tenant, et l'accès aux données d'autrui est restreint à la fois au niveau de l'API et de la base de données. Au niveau de l'API, le système vérifie que l'utilisateur appartient bien au tenant demandé. Au niveau de la base de données, les restrictions reposent sur des connexions distinctes et des mécanismes de contrôle d'accès.

Pour le stockage des fichiers, l'application utilise AWS. À ce niveau, la séparation des données est garantie par une structure de stockage stricte. Les droits d'accès aux fichiers de chaque tenant sont vérifiés au niveau de l'API.

Offline-first

L'application repose sur le principe offline-first. Cela signifie qu'elle doit fonctionner hors ligne. La synchronisation des données avec l'état global du système s'effectue dès qu'une connexion internet est disponible.

Pour mettre en œuvre cette approche, il a été décidé de diviser l'API en deux types : les API de lecture et d'écriture.

L'API de lecture ne fonctionne qu'en ligne. Elle charge les données à jour sur l'appareil mobile de l'utilisateur, où elles sont stockées dans une base de données locale. Les informations restent ainsi accessibles quelle que soit la disponibilité d'internet, ce qui permet à l'application de fonctionner en mode hors ligne. Pour optimiser les performances lors du traitement de grands volumes de données, une synchronisation partielle est utilisée : à chaque requête suivante, seules les modifications survenues dans l'état global du système pendant que l'appareil était hors ligne sont téléchargées.

L'API d'écriture est conçue pour collecter et stocker les actions des utilisateurs effectuées hors ligne. Ces actions sont enregistrées dans la base de données de l'appareil dans l'ordre où elles ont été réalisées. Dès que l'application se connecte à internet, toutes les opérations enregistrées sont envoyées au serveur et exécutées l'une après l'autre. Lorsque l'application est en ligne, les données sont envoyées directement au serveur sans être stockées localement.

Envoi d'e-mails

L'application permet d'envoyer des e-mails aux patients au nom du tenant. Pour cela, les administrateurs saisissent leur adresse e-mail dans le panneau de contrôle, qui est ensuite utilisée comme adresse d'expéditeur.

Chats par SMS

Les utilisateurs et les patients peuvent communiquer par SMS, sous forme de chat. Chaque tenant se voit attribuer un numéro de téléphone pour l'envoi et la réception des SMS. Le chat est mis à jour en temps réel.

Notifications

Les utilisateurs de l'application sont informés des changements par des notifications push et des notifications dans l'application. Ils peuvent interagir avec ces notifications pour naviguer ou effectuer rapidement des actions dans l'application.

Tâches planifiées

Le système dispose d'une logique automatique qui permet d'exécuter des actions sans intervention des utilisateurs, comme des changements de statut, la création de tâches, la génération de rapports, etc.

Intégration avec des services d'analytique

Pour l'analyse des données, l'application s'intègre à des services tiers en leur fournissant les données dans un format adapté à l'analyse. Ces systèmes exploitent les données fournies pour présenter visuellement différents indicateurs des processus métier.

API publique

En plus de l'utilisation du système dans l'application mobile, une API publique permet l'intégration avec d'autres solutions et d'autres équipes.