Le problème de facturation hospitalière que personne n'a remarqué pendant trois semaines

Introduction

Au printemps dernier, un réseau hospitalier régional du Midwest a déployé un correctif de planification dans le cadre de son processus habituel de mise à jour. Rien d’extraordinaire : il s’agissait d’une mise à jour de routine visant à synchroniser les heures de sortie avec le module de facturation. Trois semaines plus tard, un employé du service des comptes clients a remarqué un afflux de demandes de remboursement rejetées en raison d’horodatages incompatibles. Lorsque le service informatique a identifié la source du problème, il s’est avéré que le correctif avait affecté les déclarations d’assurance de plus de quatre cents patients. Personne n’avait vraiment commis d’erreur. La mise à jour avait passé avec succès tous les tests de la liste de contrôle. Mais ce n’était tout simplement pas la bonne liste de contrôle.

Cette histoire m’a marqué, car elle ne concerne pas vraiment les hôpitaux. Elle illustre ce qui se passe lorsque les systèmes qui fonctionnent discrètement en arrière-plan d’une organisation sont traités comme des produits finis plutôt que comme une infrastructure vivante nécessitant un contrôle régulier.

L’automatisation que vous avez mise en place il y a deux ans n’est pas celle que vous croyez

La plupart des entreprises mettent en place leurs premières automatisations de flux de travail pour résoudre un problème spécifique et visible. Une équipe RH en a assez de traiter manuellement les demandes de congés. Un responsable des opérations commerciales automatise l’attribution des prospects afin que les commerciaux cessent de se servir en premier. Ces automatisations sont créées à l’aide d’outils similaires à Power Automate: rapides à configurer, faciles à confier à quiconque est prêt à en assumer la responsabilité, et largement invisibles une fois qu’elles fonctionnent.

Le problème, c’est que « une fois qu’elles fonctionnent », elles deviennent permanentes. Personne ne prévoit de révision. La personne qui les a mises en place change d’équipe ou quitte l’entreprise. Pendant ce temps, l’activité évolue autour de l’automatisation : de nouveaux champs dans le CRM, une hiérarchie d’approbation différente, une fusion qui double le volume transitant par un système conçu pour la moitié de cette charge. L’automatisation continue de fonctionner exactement comme elle a été conçue, ce qui est précisément le problème. Elle a été conçue pour une entreprise qui n’existe plus tout à fait sous cette forme.

J’ai vu une entreprise de logistique découvrir qu’un flux automatisé de traitement des exceptions fonctionnait mal en silence depuis onze mois parce qu’un fournisseur avait modifié le nom d’un champ de l’API. La solution de contournement ? Quelqu’un avait réintroduit manuellement les cas ayant échoué sans en parler à personne, en supposant qu’il s’agissait d’un incident ponctuel. Ce n’est pas un échec de l’outil. C’est un échec organisationnel : celui de ne pas avoir réexaminé quelque chose que tout le monde supposait stable.

Les hôpitaux courent le même risque, mais les enjeux sont bien plus importants

Transposez ce même schéma dans l’environnement clinique et administratif d’un hôpital, et la marge d’erreur s’effondre. Le développement de logiciels hospitaliers a généralement privilégié la conformité et la disponibilité au détriment de l’adaptabilité — ce qui est compréhensible, étant donné qu’un déploiement raté peut empêcher une infirmière de consulter l’historique des traitements à 2 heures du matin. Mais cette même prudence fait que les systèmes hérités restent souvent en production bien plus longtemps qu’ils ne le devraient, rafistolés plutôt que reconstruits, car personne ne veut être celui ou celle qui mettra hors service un élément essentiel.

Il en résulte une architecture qui accumule des décisions dont personne ne se souvient avoir prises. Un module de planification communique avec le service de facturation via une intégration mise en place en 2016 pour un fournisseur que l’hôpital a cessé d’utiliser en 2019. Cela fonctionne encore, en grande partie. « En grande partie » n’est pas un terme que l’on souhaite voir associé aux données des patients.

Ce qui évolue, lentement, c’est la prise de conscience que la résilience dans l’informatique de santé ne consiste pas à éviter le changement, mais à construire des systèmes suffisamment flexibles pour absorber le changement sans avoir besoin d’un petit miracle à chaque fois qu’une réglementation change ou qu’un nouveau module de DME vient s’ajouter.

Pourquoi « si ça marche, ne changez rien » n’est pas le bon critère

Voici ce qu’il en est dans ces deux scénarios : les systèmes n’étaient pas défaillants. Ils fonctionnaient exactement comme ils avaient été configurés. C’est précisément pour cette raison que personne ne s’y est intéressé.

Par définition, les systèmes défaillants attirent l’attention : quelqu’un se plaint, quelque chose s’arrête, un ticket est ouvert. Les systèmes dangereux sont ceux qui fonctionnent bien en apparence, tout en s’éloignant discrètement de ce dont l’organisation a réellement besoin. Une automatisation de flux de travail qui s’exécute toujours, mais qui achemine les données vers le mauvais service. Une interface hospitalière qui transmet toujours les données, mais qui supprime un champ dont dépend désormais un système en aval.

L’audit n’a rien de prestigieux, mais l’alternative non plus

La solution n’est pas compliquée en théorie, même si elle est fastidieuse en pratique : programmez des revues périodiques de tout ce qui fonctionne de manière autonome, quelle que soit la qualité de ses performances passées. Demandez à qui en est responsable aujourd’hui. Demandez ce qui a changé en amont et en aval depuis sa mise en place. Demandez si quelqu’un remarquerait que cela cesse de fonctionner discrètement demain.

La plupart des organisations négligent cette étape, car elle ressemble davantage à de la maintenance qu’à une avancée, et la maintenance bénéficie rarement d’un budget ou d’éloges. Mais le coût de cette négligence ne disparaît pas : il attend simplement, en silence, le moment où quelqu’un du service des comptes clients remarquera que les chiffres ne concordent pas.