2016 - 2019 · Ingénieur logiciel → Responsable d'équipe → Engineering Manager
Epic Systems
Direction de deux équipes d'ingénierie chez Epic : Patient History pendant une refonte complète, puis Provider/Nurse Scheduling, le principal point d'entrée clinique du produit Ambulatory d'Epic.
Contexte
Les logiciels d'Epic sont au cœur des soins dans une grande partie des hôpitaux américains. J'ai rejoint l'équipe History en 2016 comme développeur, puis j'en ai pris la responsabilité quinze mois plus tard. En 2019, j'ai ajouté à mon périmètre une seconde équipe, Provider/Nurse Scheduling, le principal point d'entrée clinique pour les utilisateurs d'Ambulatory. À cet endroit du produit, chaque livraison touche des milliers de cliniciens. Il est impossible de revenir discrètement sur une décision de modèle de données lorsque les clients y ont déjà accumulé des années de données patient.
La difficulté principale
Réécrire un système clinique en production
J'ai mené l'équipe Patient History à travers une refonte complète. Dans cet environnement, la contrainte ne tient pas à la nouvelle implémentation. Chaque client possède des années de données patient dans l'ancien système, des milliers de cliniciens dépendent de comportements qu'ils maîtrisent déjà et aucun créneau de maintenance ne permet à un hôpital d'interrompre les soins. La nouvelle version a été livrée avec des incidents mineurs, sans rupture significative. Pour un système placé à cet endroit, c'est le seul résultat qui compte.
Un modèle d'instance mutualisée pour les petits hôpitaux
Adopter Epic restait financièrement hors de portée des petites structures. Avec le responsable de la R&D et des collègues des équipes Commerciale, Juridique, Technical Services et Implémentation, j'ai contribué à concevoir un modèle dans lequel plusieurs petits clients partagent une même instance. Un modèle existant permettait déjà à un grand hôpital d'étendre son instance à des établissements plus petits de sa région, mais concentrait toute la charge informatique et de gouvernance sur cet hôte. Notre approche conservait le même chemin de code tout en répartissant la responsabilité opérationnelle entre les membres. Elle devenait ainsi viable pour des clients qui ne pouvaient se rattacher à aucun hôte existant.
Également chez Epic
Les données d'identité se propagent partout
Epic a revu la gestion des noms d'usage dans le cadre d'une initiative plus large sur l'identité, et ce changement a provoqué des escalades. Le nom d'un patient ne se résume pas à un champ : il apparaît dans la planification, les en-têtes du dossier, les documents imprimés, les communications avec le patient et des dizaines d'intégrations en aval. Les systèmes de santé avaient par ailleurs des exigences cliniques et juridiques réellement différentes quant à son affichage. Aucun comportement global par défaut ne pouvait convenir à tout le monde.
J'ai été chargé de coordonner la réponse de la R&D. La solution retenue était un mécanisme de substitution appliqué à bas niveau, qui permettait à chaque organisation de maintenir l'affichage du nom légal dans l'ensemble du système plutôt que de devoir passer en revue, dans l'urgence, plus de 10 000 configurations avant sa prochaine mise à niveau. Plus de 30 % des clients l'ont adopté, et le sujet a cessé de provoquer des escalades.
Management d'équipes
Deux équipes, jusqu'à 7 développeurs. Réduction de 80 % du backlog QA. Revues trimestrielles des effectifs avec le responsable produit pour chaque équipe Ambulatory, selon une trame fixe : qualité, avancement des projets, charge de travail et bien-être de l'équipe. Mise en place de Scrum pour l'équipe History. Entretiens de candidats développeurs pour la R&D.