Table des matières:
Premierement ne faites pas de mal! Cet édit - paraphrasé du serment d'Hippocrate - imprègne les soins de santé professionnels, comme il l'a fait depuis l'aube de la médecine occidentale il y a environ 2500 ans. Tout le monde peut apprécier la simplicité et la signification de ce mantra. Si vous ne faites rien d'autre en tant que professionnel de la santé, ne blessez pas au moins votre patient.
Écrit dans le courant sous-jacent de cette phrase, vous pouvez trouver une humilité indéniable. En fait, pour toutes les voies diverses et diverses de la science, il existe un axiome critique: être toujours prêt à remettre en question vos hypothèses. Nous ne savons que ce que nous savons, et nous ne savons pas encore tout, et nous ne le saurons jamais. Que cette sagesse serve d'avertissement à vos prescriptions les plus fortes.
Ensuite, il y a la partie faisant. Dans toute entreprise de la vie, on espère savoir quelque chose d'important, puis prendre les mesures appropriées. Faire attention est aussi prudent, et quand on prend soin de la vie des autres, le sérieux est de mise. Avec cette perspective comme toile de fond et une compréhension des technologies de l'information (TI) sous nos ceintures, jetons un coup d'œil au déploiement de HealthCare.gov, le produit phare souvent caractérisé de la Loi sur les soins abordables, alias "Obamacare".
Soutien de la vie
Comment puis-je être franc? HealthCare.gov était mort à son arrivée. La transparence collective indique maintenant que les six personnes se sont inscrites le premier jour, le 1er octobre. Six. Seulement 32 994 de moins que l'objectif quotidien de 33 000. Et tandis que les problèmes de «capacité» étaient présentés comme des distinctions détournées de la demande, quiconque connaissant la dynamique du Web savait mieux.
"Ce n'est pas un problème non résolu", note le Dr Robin Bloor, scientifique des données et cofondateur de The Bloor Group. "La Hollande a un tel échange."
En fait, les Néerlandais sont en avance sur le jeu depuis deux décennies maintenant, avec de nombreuses leçons apprises. Les Suisses ont également une certaine expérience, et bien sûr le Massachusetts a MAHealthConnector.org, soi-disant "RomneyCare".
Bloor a poursuivi en disant que 40 ans d'expérience informatique ont prouvé que les grands projets comportent toujours de gros risques.
"Faire un grand projet, un risque élevé un risque d'échec. Avoir trois ans et demi sonne comme dans un temps moderne, ce serait suffisant, mais voici un projet à haut risque et tout s'est mal passé, "Dit Bloor.
Il était très franc sur la façon dont les tests d'intégration ont été effectués pour HealthCare.gov.
«La dernière chose qui m'a fait, m'a presque fait éclater de rire, ce n'est pas un test d'intégration jusqu'à deux semaines avant de passer en direct - et c'est comme, comment pourriez-vous faire ça avec quelque chose comme ça? Comment avez-vous pu? Dit Bloor.
Partageant cette perspective est un vétéran du gouvernement fédéral et collègue scientifique des données, le Dr Geoffrey Malafsky de Phasic Systems Inc. Malafsky a récemment offert une évaluation détaillée d'une heure du déploiement de HeathCare.gov et a commenté les décisions stratégiques et tactiques prises . Par-dessus tout, il pointe du doigt le protocole d'acquisition du gouvernement fédéral.
"L'un des points de défaillance critiques qui imprègne particulièrement les projets informatiques gouvernementaux est cette notion héritée, archaïque et obsolète selon laquelle vous pouvez articuler toute la logique métier nécessaire avec un processus d'exigences linéaires. Cela ne fonctionne pas fondamentalement avec les grands systèmes informatiques", a-t-il déclaré.
Son point de vue est que les grands systèmes informatiques perturberont même les planificateurs les plus intelligents. Vous ne savez jamais d'où viendront les problèmes, où vous devrez fournir une assistance supplémentaire ou quel type de dépannage vous vous retrouverez engagé. Par conséquent, c'est une mauvaise idée de contraindre le processus de conception en forçant les ingénieurs de projet à tout prévoir ils auront besoin d'avance.
Pour Malafsky, ce qui complique les choses, c'est que les responsables des achats du gouvernement fédéral sont devenus si puissants - en raison des énormes sommes d'argent qu'ils contrôlent - qu'ils contrôlent essentiellement la façon dont les grands projets informatiques vont de l'avant. Cela place les responsables ministériels dans le rôle de suppliant et insère un élément de risque dans une procédure cruciale au centre de toute initiative informatique importante: le choix des bons outils, technologies et entrepreneurs.
"Les personnes qui seront le plus bruyamment en désaccord avec cette déclaration sont appelées des professionnels de l'acquisition, et je les encourage à se présenter chez moi et nous allons nous asseoir et en débattre, car j'ai beaucoup de preuves empiriques pour étayer cela", Malafsky m'a dit.
Stratégie du site
Une grande question à se poser est de savoir pourquoi le gouvernement a adopté une architecture aussi complète pour ce site Web.
"Si le programme gouvernemental global est mis en place de telle sorte que les compagnies d'assurance possèdent effectivement le client après avoir obtenu un engagement, alors pourquoi ne pas simplement pousser le trafic vers le canal existant de l'environnement d'interaction client que les compagnies d'assurance ont déjà? Oui, elles pourraient doivent augmenter les leurs, mais ce serait une raison commerciale valable, car ils vont maintenant obtenir de nouveaux clients ", a déclaré Malafsky.
Le pionnier des logiciels de sécurité de renommée mondiale (et maintenant quelque peu tristement célèbre), John McAfee, a également commenté cette stratégie récemment, faisant des remarques controversées sur le "Neil Cavuto Show" sur Fox News:
"Oh, c'est vraiment mauvais", a déclaré McAfee. "Quelqu'un a fait une grave erreur, non pas en concevant le programme mais en mettant simplement en œuvre l'aspect Web de celui-ci. Je veux dire, par exemple, n'importe qui peut mettre en place une page Web et prétendre être un courtier pour ce système … tout pirate peut mettre un site Web, le rendre extrêmement compétitif, et en raison de la nature du système - et ce sont les soins de santé, après tout - ils peuvent vous poser les questions les plus intimes, et vous allez y répondre librement. "
En ce qui concerne l'architecture Web elle-même, Malafsky souligne l'évidence - Internet n'a pas été conçu pour exécuter des applications complexes. C'était le travail de l'ordinateur central à l'époque où le Web en était à ses balbutiements. Le point de conception d'Internet était plutôt le partage d'informations simple via des pages individuelles réparties sur un large réseau d'ordinateurs. Dans la conception de systèmes, l'objectif est de construire quelque chose qui fonctionne. Incorporer la complexité pour elle-même est mal avisé, carrément sacrilège et presque toujours une recette pour un désastre.
Dans sa propre analyse approfondie de ce qui n'a pas fonctionné avec HealthCare.gov, le Washington Post a publié un graphique désormais célèbre qui décrit les différents défis rencontrés par le site. Le langage utilisé par le journal pour décrire le site est en fait assez révélateur, surtout si l'on considère qu'il s'agit du journal établi de Washington, DC, l'épicentre du gouvernement fédéral américain:
HealthCare.gov, construit par 55 entrepreneurs, est l'un des logiciels les plus complexes jamais créés pour le gouvernement fédéral. Il communique en temps réel avec au moins 112 systèmes informatiques différents à travers le pays. Au cours des 10 premiers jours, il a reçu 14, 6 millions de visites uniques, selon l'administration Obama.
Source: The Washington Post
Sans doute, par définition, pour quelqu'un d'affirmer qu'il a un logiciel, il doit être vrai que le logiciel fonctionne réellement. Sinon, vous disposez d'une compilation de code qui ne constitue pas encore un logiciel. Mis à part cela, notez les chiffres indiqués, en particulier la partie concernant la communication "en temps réel" avec 112 systèmes informatiques différents à travers le pays. C'est un parfait exemple de glorification de la complexité pour elle-même.
"Nous savons qu'une autre possibilité est d'avoir créé un système de courtage Web simple et très simple, que tout ce qu'il fait est par un code de serveur d'application très simple et encore plus simple Javascript côté client, crée une interface très agréable qui produit des données cumulées pour les gens" ", A déclaré Malafsky. "Voici ce que vous pouvez faire: étape par étape; étape par étape. Ensuite, toute action qui se produit peut être effectuée au point de sélection et envoyée à quelqu'un qui sera réellement propriétaire du programme." Bien sûr, ce «quelqu'un» fait référence aux compagnies d'assurance qui détiendront les polices de toute façon.
The Graphic Graphic
Les concepteurs de systèmes du monde entier ont dû grincer des dents en voyant ce graphique. Jetons un coup d'œil aux différentes étapes décrites, et en particulier, aux graves problèmes qui se posent avec une architecture aussi ambitieuse. Tout d'abord, nous considérerons le nombre de transactions potentielles qui ont échoué jusqu'à présent, la plupart d'entre elles en raison de délais d'expiration des logiciels - des cas où une partie du processus de transaction ne reçoit pas ses données nécessaires dans un délai acceptable.
"Chaque logiciel de ce graphique avait ses propres délais d'attente, et ce n'est même pas un seul délai d'attente. Cela peut être plus", a déclaré Malafsy. "L'expiration de l'un de ceux-ci tuera la transaction entière. Certains d'entre eux sont faciles à configurer et à surveiller, comme les fichiers journaux. Ce sont comme les délais d'attente sur le serveur Web et le serveur d'applications. Certains sont plus opaques. Vous avez bases de données avec simultanéité et déclencheurs, mais elles sont multi-interaction. Si vous faites vraiment une plongée profonde dans la façon dont les bases de données fonctionnent, ce n'est pas une jolie vue. " (Apprenez les bases du fonctionnement des bases de données dans notre didacticiel sur les bases de données.)
«Les serveurs de bases de données adorent dire:« Nous gardons tout en ordre. » Pas vraiment ", a déclaré Malafsky. La seule façon d'obtenir des performances et de vraiment les gérer est qu'il existe une série de fichiers horodatés qui sont créés sur le stockage, un stockage persistant et qu'ils ne sont pas regroupés en un seul. ensemble complet et précis de données disponibles pour tout le monde à tout moment car cela prend trop de temps. Cela tuerait la latence transactionnelle. Vous devez regarder dans ces détails, puis cela est remonté via une interface de gestion - et cela passe par une très belle sophistication des noms comme des déclencheurs et des accès simultanés - mais cela signifie essentiellement que cela prend beaucoup de temps pour aller chercher les données, mettre à jour les données, et si je ne peux pas le faire avant qu'une autre demande arrive, je vais juste vous dire, '' Oubliez ça. Je suis fermé pour affaires. ""
- "La porte d'entrée"
Le graphique du Washington Post comprend une information très curieuse juste au sommet de sa première section "problème", où il est dit que "l'administration Obama a décidé fin septembre d'exclure pour l'instant une fonctionnalité qui aurait permis aux gens de magasiner plans de santé sans créer au préalable un compte en ligne. "
Sensationnel. Tout d'abord, est-ce vraiment une "fonctionnalité" qui a été exclue? Nous parlons de flux de site fondamental. À l'origine, le plan était de permettre aux gens de faire le tour, puis au moment opportun, d'envisager d'enregistrer un compte.
Certains critiques ont émis l'hypothèse que ce changement de dernière minute (en soi un mouvement incroyablement risqué avec un projet de cette envergure), montre que l'administration savait que le site ne fonctionnait pas bien au cours des dernières semaines précédant le lancement le 1er octobre. . Au lieu de cela, l'idée est devenue de capturer toutes les informations de ceux qui avaient besoin d'une assurance, de sorte que des efforts de marketing pourraient leur être déployés quelque part en aval une fois que le site serait fonctionnel.
Du point de vue de l'utilisabilité et de la capacité, cette décision de dernière minute a mis à rude épreuve la base de données du site. Cela explique toutes les anecdotes de personnes ne pouvant pas s'inscrire ou obligées de changer leurs mots de passe. Et soyons honnêtes ici. Existe-t-il un problème plus complètement résolu sur le World Wide Web que le processus de création d'un compte d'utilisateur? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - même la classe de tricot de votre grand-mère - a sa propre forme d'inscription dynamique ces jours-ci, avec des fonctions de désabonnement, de transfert et d'autres fonctionnalités fondamentales intégrées. - enregistrement
Quand est venu le temps de s'inscrire sur HealthCare.gov, les entrepreneurs disent: "La communication entre certains de ces systèmes ne fonctionnait pas correctement, ce qui signifie que de nombreux utilisateurs n'ont pas réussi à créer un compte."
Quelle? Quels systèmes? Nous parlons d'une base de données clients! Les «systèmes» seraient alors le client Web et la base de données clients. Quels autres systèmes étaient impliqués? Cette "explication" particulière n'a aucun sens. - Preuve d'identité
Ensuite, une preuve d'identité. Pour cette étape, aucun problème n'est répertorié, ce qui est également curieux. Experian est répertorié comme l'agent tiers qui "vérifiera" l'identité de quelqu'un. Il ne fait aucun doute que la résolution d'identité est un problème grave qui doit être résolu. La plupart des compagnies d'assurance utilisent votre numéro de sécurité sociale, ainsi que des fournisseurs tiers comme Experian. N'y a-t-il vraiment aucun problème avec cette étape?
Nous savons à coup sûr, grâce à de nombreuses anecdotes, vérifiées par la documentation présentée, que HealthCare.gov a certainement connu une violation d'informations confidentielles. Malafsky souligne que les problèmes de qualité des données sont beaucoup plus graves que les problèmes de capacité. (Et Bloor note que si les problèmes de capacité étaient vraiment les problèmes, ils auraient dû être résolus en quelques jours, pas en semaines. Vous pouvez ajouter du matériel, virtualiser, faire un certain nombre de choses pour les problèmes de capacité.)
Non, les problèmes de qualité des données sont vraiment dangereux. Et l'aspect le plus troublant de tous est le type de problèmes de qualité des données qui sont survenus. Il y a des histoires de personnes s'inscrivant, puis recevant des documents d'admissibilité confidentiels appartenant à d'autres inscrits! Cela sent un design absolument épouvantable sous les couvertures. N'utilisent-ils pas une sorte de code d'identification universel pour chaque personne?
"La décision intelligente serait de créer un identifiant universellement unique (UUID), de stocker des valeurs cryptées - notez au pluriel - de ce qui pourrait être des informations uniques (SSN, DOB, âge, biométrie), puis de les évaluer pour rechercher des preuves d'une personnalité unique", Dit Malafsky.
Que quelqu'un puisse recevoir les documents confidentiels d'une autre personne est indiciblement mauvais et démontre des problèmes de cartographie très graves au plus profond du ventre de la bête. - Admissibilité
OK, les amis. Voici où la vie devient intéressante! Si votre transaction n'avait pas expiré maintenant, elle l'a presque certainement fait à cette étape. Selon le graphique du Washington Post, "Le système doit déterminer l'admissibilité à une aide financière en envoyant les informations personnelles du consommateur à un Data Hub qui contracte des dizaines d'agences fédérales et étatiques."
Essayer d'exécuter une transaction sur trois ou quatre systèmes clés est un véritable défi. Essayer de frapper "des dizaines" d'agences étatiques et fédérales "en temps réel" est hors de propos et totalement inutile. Malafsky n'a pris qu'un seul point d'interaction pour plaider sa cause:
"L'un des plus évidents ici est d'obtenir des données financières par personne pour déterminer si elles méritent une subvention ou quel serait leur prix, alors nous allons à l'IRS. Maintenant, nous avons un lien là-bas, mais ce lien est en direct Cela signifie que lorsque l'utilisateur est assis là, devant son écran d'ordinateur, il doit établir un lien avec les systèmes IRS. Dans un monde parfait, ce lien se produit, les ordinateurs parlent, j'obtiens mon résultat et je reviens.
"Qu'en est-il dans le monde réel? Qu'en est-il lorsque les systèmes IRS sont surchargés? Qu'en est-il lorsqu'ils sont à pleine capacité? Qu'en est-il quand peut-être qu'ils effectuent la maintenance? Qu'en est-il d'un réseau entre le centre d'exploitation du réseau d'entrée de gamme? Page Web que le client voit au centre IRS? Peut-être y a-t-il des problèmes. Peut-être qu'il y a un virus. Peut-être qu'il y a un cheval de Troie qui court et que les télécoms ont arrêté les choses pour résoudre ce problème. Cela tuera la transaction à partir du moment de vue de l'utilisateur. Ce n'est là qu'un des nombreux points de cette architecture ", a déclaré Malafsky.
Son point de vue est que chacun de ces systèmes - comme cette archive Web a été conçue pour HealthCare.gov - chacun d'entre eux est un talon d'Achille potentiel. C'est une situation sans issue. Et encore une fois, ce n'est pas nécessaire du point de vue du flux de travail. Il y a un certain nombre de points en cours de route où le flux de travail pourrait être complété par des data marts en temps quasi réel, des data marts en temps opportun, voire une intervention humaine pour résoudre les principaux points de défaillance de l'automatisation.
La grande erreur stratégique consistait donc à créer un site incroyablement complexe. - Shopping pour un plan
Rappelez-vous: c'était censé être le flux du site d'origine. Les internautes achèteraient d'abord un plan d'assurance. Puis, quand ils ont trouvé quelque chose d'intéressant, ils pouvaient ouvrir un compte, vérifier les subventions s'ils le souhaitaient et finalement acheter un plan.
Selon le graphique, "certaines personnes à faible revenu se font dire qu'elles ne sont pas éligibles aux subventions ou ne sont pas éligibles à Medicaid, même si elles le devraient". La question ici devient: Pourquoi ce problème est-il répertorié à l'étape 5 au lieu de l'étape 4? Il s'agit d'un problème lié au fait que l'étape précédente n'a pas été calculée correctement et n'est donc pas correctement prise en compte dans l'étape 5. - Traduction d'assurance
Dans notre monde, nous appelons cette partie ETL. C'est aussi un problème résolu que l'enregistrement du site.
- Inscription à l'assurance
Le Saint-Graal! Mais attendez, il y a un dernier "problème", selon les entrepreneurs de HealthCare.gov: "Les rapports, connus sous le nom de 834, sont parfois déroutants et duplicatifs, ce qui rend difficile pour les compagnies d'assurance de savoir qui sont réellement leurs nouveaux clients."
Prenons un moment de silence pour apprécier celui-ci…
Donc, oui, en réalité, une compagnie d'assurance doit savoir qui elle assure vraiment. C'est un élément assez critique. Il en va de même pour un travailleur d'urgence sachant quelle personne traiter, ou un médecin sachant dans quelle poitrine un cœur doit être transplanté. Dans le secteur des médias, nous pourrions caractériser cette petite chansonnette comme un cas où nos entrepreneurs fédéraux ont réussi à enterrer la lede avec succès. - Couverture
Enfin et surtout, le graphique indique que "les responsables de l'administration affirment que les acheteurs ont déposé plus de 700 000 demandes d'assurance maladie. Certains d'entre eux sont passés par HealthCare.gov et d'autres par les marchés publics. Mais les responsables refusent de dire combien de personnes se sont inscrites dans un plan."
Contrôle manuel
Peut-être que la courbe la plus nette lancée récemment dans le mélange a été la décision de promouvoir les applications papier en raison des problèmes de fonctionnalité du site. Malheureusement, même les formulaires papier doivent être soumis sur le site qui ne fonctionne pas. Par définition, ce n'est pas un remplacement manuel. Par définition, un remplacement manuel doit permettre à quelqu'un ou à quelque chose de remplacer manuellement le système automatisé.
Et maintenant, au moment de la publication de cet article, nous apprenons que pour la relance de HealthCare.gov, l'administration compte davantage sur les compagnies d'assurance pour résoudre les problèmes. Devinez ce que cela signifie - je parie que vous donuts en dollars (oui, c'était l'inverse), que ce qui se passe en ce moment est un cas de rip-and-replace généralisé. Plus précisément, les programmeurs et les ingénieurs ont probablement supprimé de nombreuses "connexions en temps réel" et d'autres middleware extrêmement coûteux qui ont excité les rédacteurs du Washington Post. Remplacer tout ce code complexe sont des connexions beaucoup plus simples et à latence plus élevée qui sont alimentées par une gamme de data marts liés via plusieurs environnements de lots aux divers systèmes étatiques et fédéraux.
En d'autres termes, le type de solution que Malafsky, Bloor et McAfee proposent est où nous allons. Et tout ce code de spaghetti de fantaisie que ces entrepreneurs fédéraux ont dépensé un demi-milliard de dollars pour construire au cours des trois dernières années et demie? Dans le conteneur pour objets tranchants.
Plomb enterré
Et une dernière note: Selon le témoignage devant le Congrès de Henry Chao, le directeur général adjoint de l'information des Centers for Medicare et Medicaid Services, le système de paiement qui remboursera aux compagnies d'assurance toutes ces subventions fédérales? Il n'a pas encore été construit! Cela signifie que ce pourrait être le premier site de commerce électronique à grande échelle jamais lancé sans moyen de transfert d'argent.
