Sommario:
Innanzitutto, non fare del male! Questo editto - parafrasato dal giuramento di Ippocrate - pervade l'assistenza sanitaria professionale, come è accaduto dall'alba della medicina occidentale circa 2.500 anni fa. Chiunque può apprezzare la semplicità e il significato di questo mantra. Se non fai altro come medico, almeno non ferire il tuo paziente.
Scritto nella corrente sotterranea di quella frase, puoi trovare un'innegabile umiltà. In effetti, per tutte le varie e varie strade della scienza, esiste un assioma critico: sii sempre disposto a mettere in discussione le tue assunzioni. Sappiamo solo ciò che sappiamo e sicuramente non sappiamo ancora tutto, né lo faremo mai. Lascia che quella saggezza serva da cautela per le tue prescrizioni più forti.
Poi c'è la parte che sta facendo. In ogni sforzo della vita, si spera di sapere qualcosa di importante, quindi intraprendere le azioni appropriate. L'attenzione è altrettanto attenta e quando si prende cura della vita degli altri, la serietà è necessaria. Con questa prospettiva come la nostra tela e una comprensione della tecnologia dell'informazione (IT) sotto le nostre cinture, diamo un'occhiata al lancio di HealthCare.gov, il fiore all'occhiello spesso caratterizzato dell'Affordable Care Act, noto anche come "Obamacare".
Supporto vitale
Quanto posso essere schietto? HealthCare.gov era morto all'arrivo. La trasparenza collettiva ora dice che tutte e sei le persone si sono iscritte il primo giorno, il 1 ottobre. Sei. Solo 32.994 a corto dell'obiettivo giornaliero di 33.000. E mentre i problemi di "capacità" venivano propagandati come riconoscimenti di domanda retroattivi, chiunque avesse conoscenza delle dinamiche del Web lo sapeva meglio.
"Questo non è un problema irrisolto", osserva il dottor Robin Bloor, scienziato di dati e co-fondatore di The Bloor Group. "L'Olanda ha un tale scambio."
In effetti, gli olandesi sono in vantaggio da due decenni ormai, con molte lezioni apprese. Anche gli svizzeri hanno una certa esperienza e, naturalmente, il Massachusetts ha MAHealthConnector.org, il cosiddetto "RomneyCare".
Bloor ha continuato affermando che 40 anni di esperienza IT hanno dimostrato che i grandi progetti comportano sempre grandi rischi.
"Fai un grande progetto, alto rischio di fallimento. Avere tre anni e mezzo suona come, in un giorno moderno, sarebbe abbastanza, ma ecco un progetto ad alto rischio e tutto è andato male, "Disse Bloor.
Era molto sincero sul modo in cui venivano eseguiti i test di integrazione per HealthCare.gov.
"L'ultima cosa che mi ha fatto, quasi mi ha fatto scoppiare a ridere, non è stato un test di integrazione fino a due settimane prima di andare in diretta - ed è proprio come, come hai potuto farlo con qualcosa del genere? Come hai potuto?" Disse Bloor.
Condividendo questa prospettiva è un veterano appaltatore federale e un collega scienziato di dati, il dott. Geoffrey Malafsky di Phasic Systems Inc. Malafsky ha recentemente offerto una valutazione dettagliata di un'ora del lancio di HeathCare.gov e ha commentato le decisioni strategiche e tattiche prese . Soprattutto, punta il dito sul protocollo di acquisizione del governo federale.
"Uno dei punti critici di fallimento che permea in particolare i progetti IT governativi è questa nozione legacy, arcaica e obsoleta che è possibile articolare tutta la logica aziendale necessaria con un processo di requisiti lineari. Che fondamentalmente non funziona con i grandi sistemi IT", ha detto.
Il suo punto è che i grandi sistemi IT guideranno anche i pianificatori più intelligenti. Non sai mai da dove verranno i problemi, dove dovrai fornire ulteriore supporto o in quale tipo di risoluzione dei problemi ti troverai coinvolto. Di conseguenza, è una cattiva idea limitare il processo di progettazione costringendo gli ingegneri del progetto ad anticipare tutto avranno bisogno in anticipo.
Questioni complicate, afferma Malafsky, sono il fatto che i funzionari degli appalti pubblici del governo federale sono diventati così potenti - a causa delle enormi quantità di denaro che controllano - che hanno essenzialmente il controllo di come vanno avanti i grandi progetti IT. Ciò pone i funzionari dipartimentali nel ruolo di supplicante e inserisce un elemento di rischio in una procedura cruciale al centro di qualsiasi iniziativa IT significativa: la scelta degli strumenti, delle tecnologie e degli appaltatori giusti.
"Le persone che saranno in gran parte in disaccordo con questa affermazione si chiamano professionisti dell'acquisizione e li incoraggio a presentarsi a casa mia e ci sediamo a discutere di questo, perché ho molte prove empiriche a sostegno di ciò", Malafsky disse.
Strategia del sito
Una grande domanda da porsi è perché il governo abbia adottato un'architettura così completa per questo sito Web.
"Se il programma governativo globale è impostato in modo tale che le compagnie assicurative siano effettivamente proprietarie del cliente dopo aver ottenuto un impegno, perché non spingere semplicemente il traffico verso il canale dell'ambiente di interazione esistente con il cliente che le compagnie assicurative già hanno? Sì, potrebbero hanno bisogno di aumentare il proprio, ma questo sarebbe un valido motivo commerciale perché ora avranno nuovi clienti ", ha detto Malafsky.
John McAfee, pioniere del software di sicurezza di fama mondiale (e ora un po 'famigerato), ha recentemente commentato questa strategia, facendo alcune osservazioni controverse sul "Neil Cavuto Show" su Fox News:
"Oh, è davvero un male", ha detto McAfee. "Qualcuno ha commesso un grave errore, non progettando il programma ma semplicemente implementandone l'aspetto Web. Voglio dire, ad esempio, chiunque può creare una pagina Web e dichiarare di essere un broker per questo sistema … qualsiasi hacker può mettere un sito Web, renderlo estremamente competitivo e, a causa della natura del sistema - e questa è l'assistenza sanitaria, dopotutto - possono farti le domande più intime e tu risponderai liberamente. "
Rispetto alla stessa architettura Web, Malafsky sottolinea l'ovvio: che Internet non è stato creato per eseguire applicazioni complesse. Quello era il lavoro del mainframe nei giorni in cui il Web era agli inizi. Piuttosto, il punto di progettazione per Internet era la semplice condivisione di informazioni tramite singole pagine distribuite su una vasta rete di computer. Nella progettazione dei sistemi, l'obiettivo è costruire qualcosa che funzioni. Incorporare la complessità per se stessa è sconsiderato, decisamente sacrilego e quasi sempre una ricetta per il disastro.
Nel suo approfondimento su ciò che è andato storto con HealthCare.gov, il Washington Post ha pubblicato un grafico ormai famoso che illustrava le varie sfide affrontate dal sito. Il linguaggio usato dall'articolo per descrivere il sito è in realtà abbastanza rivelatore, specialmente se si considera che questo è il giornale affermato di Washington, DC, epicentro del governo federale degli Stati Uniti:
HealthCare.gov, costruito da 55 appaltatori, è uno dei software più complessi mai creati per il governo federale. Comunica in tempo reale con almeno 112 diversi sistemi informatici in tutto il paese. Nei primi 10 giorni, ha ricevuto 14, 6 milioni di visite uniche, secondo l'amministrazione Obama.
Fonte: The Washington Post
Probabilmente, per definizione, affinché qualcuno asserisca di avere un software, deve essere vero che il software funziona davvero. Altrimenti, hai una raccolta di codice che non costituisce ancora un pezzo di software. A parte questo, annota i numeri elencati, in particolare la parte sulla comunicazione "in tempo reale" con 112 diversi sistemi informatici in tutto il paese. Questo è un perfetto esempio di glorificante complessità per se stessa.
"Sappiamo che un'altra possibilità è quella di aver creato un sistema di intermediazione Web semplice e molto semplice, che tutto ciò che fa è tramite un codice server app molto semplice e Javascript anche sul lato client ancora più semplice, crea un'interfaccia molto piacevole che produce dati arrotolati per le persone ", Ha detto Malafsky. "Ecco cosa puoi fare: passare attraverso questo; passare attraverso questo. Quindi qualsiasi azione che si verifica può essere eseguita nel punto di selezione ed essere inviata a qualcuno che sarà effettivamente proprietario del programma." Naturalmente, "qualcuno" si riferisce alle compagnie assicurative che saranno comunque proprietarie delle polizze.
La grafica
I progettisti di sistemi di tutto il mondo devono essersi arrabbiati nel vedere quella grafica. Diamo un'occhiata ai diversi passaggi delineati, e in particolare ai problemi gravi che sorgono con un'architettura così ambiziosa. Innanzitutto, considereremo il numero di potenziali transazioni finora fallite, la maggior parte a causa di timeout del software, casi in cui una parte del processo di transazione non riceve i dati necessari entro un periodo di tempo accettabile.
"Ogni singolo software in quella grafica aveva i suoi timeout, e non è nemmeno un timeout. Può essere di più", ha detto Malafsy. "La scadenza di uno di questi ucciderà l'intera transazione. Alcuni di questi sono facili da configurare e monitorare, come i file di registro. Questi sono come i timeout sul server Web e sul server delle app. Alcuni sono più opachi. Hai database con concorrenza e trigger, ma sono multi-interazione. Se fai davvero un tuffo nel modo in cui funzionano i database, non è una bella vista. " (Scopri le basi di come funzionano i database nel nostro tutorial sui database.)
"I server di database adorano dire: 'Manteniamo tutto in ordine." Non proprio ", ha detto Malafsky. L'unico modo in cui possono ottenere le prestazioni e gestirle veramente è che ci sono una serie di file timestamp che vengono creati sull'archiviazione, sull'archiviazione persistente e non sono raggruppati in uno set completo e accurato di dati che è disponibile per chiunque in qualsiasi momento perché richiede troppo tempo. Ciò ucciderebbe la latenza transazionale. Devi guardare in quei dettagli e poi è arrotolato attraverso un'interfaccia di gestione - e che va da alcuni molto sofisticati nomi come trigger e concorrenza - ma fondamentalmente significa che ci vuole un sacco di tempo per ottenere i dati, aggiornare i dati e se non riesco a farlo prima che arrivi un'altra richiesta, ti dirò solo, " Lascia perdere. Sono chiuso per affari. ""
- "La porta di fronte"
La grafica del Washington Post include un curioso pezzo di informazione proprio in cima alla cima nella sua prima sezione "problema", in cui si dice che "l'amministrazione Obama ha deciso a fine settembre di escludere per ora una caratteristica che avrebbe permesso alla gente di fare acquisti piani sanitari senza prima creare un account online ".
Wow. Prima di tutto, è davvero una "caratteristica" che è stata esclusa? Stiamo parlando del flusso fondamentale del sito. Inizialmente, il piano era di consentire alle persone di fare acquisti, quindi al momento opportuno, prendere in considerazione la registrazione di un account.
Alcuni critici hanno ipotizzato che questo cambiamento dell'ultimo minuto (di per sé una mossa incredibilmente rischiosa con un progetto così grande), mostra che l'amministrazione sapeva che il sito non funzionava bene nelle ultime due settimane precedenti il lancio del 1 ottobre . Invece, l'idea è diventata quella di catturare tutte le informazioni di coloro che avevano bisogno di un'assicurazione, in modo che gli sforzi di marketing potessero essere fatti loro da qualche parte lungo la linea una volta che il sito era funzionante.
Dal punto di vista dell'usabilità e della capacità, questa mossa dell'ultimo minuto ha messo a dura prova qualunque base di database avesse il sito. Questo spiega tutti gli aneddoti delle persone che non sono in grado di registrarsi o che sono costretti a cambiare le loro password. E siamo onesti qui. Esistono problemi più risolti in tutto il World Wide Web rispetto al processo di impostazione di un account utente? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - anche la classe di lavoro a maglia di tua nonna - ha una propria forma di iscrizione dinamica in questi giorni, con annullamento dell'iscrizione, inoltro e altre caratteristiche fondamentali. - Registrazione
Quando è arrivato il momento di registrarsi su HealthCare.gov, gli appaltatori affermano che "La comunicazione tra alcuni di questi sistemi non funzionava correttamente, il che significa che molti utenti non erano in grado di creare correttamente un account".
Che cosa? Quali sistemi? Stiamo parlando di un database di clienti! I "sistemi" sarebbero quindi il client Web e il database dei clienti. Quali altri sistemi erano coinvolti? Questa particolare "spiegazione" non ha senso. - Prova di identità
Successivamente, prova dell'identità. Per questo passaggio, non sono elencati problemi, il che è anche curioso. Experian è elencato come agente di terze parti che "verificherà" l'identità di qualcuno. Senza dubbio, la risoluzione dell'identità è un problema serio che deve essere affrontato. La maggior parte delle compagnie assicurative usa il tuo numero di previdenza sociale, così come i fornitori di terze parti come Experian. Non ci sono davvero problemi con questo passaggio?
Sappiamo per certo da numerosi aneddoti, verificati dalla documentazione presentata, che HealthCare.gov ha sicuramente sperimentato calzoni di informazioni riservate. Malafsky sottolinea che i problemi di qualità dei dati sono molto più gravi di quelli relativi alla capacità. (E Bloor osserva che se i problemi di capacità fossero davvero i problemi, avrebbero dovuto essere risolti in giorni, non settimane. È possibile aggiungere hardware, virtualizzare, fare un numero qualsiasi di cose per problemi di capacità.)
No, i problemi di qualità dei dati sono davvero pericolosi. E l'aspetto più preoccupante di tutti è il tipo di problemi di qualità dei dati che sono sorti. Ci sono storie di persone che si iscrivono, quindi ricevono documenti di idoneità riservati appartenenti ad altri registranti! Questo sa di un design assolutamente spaventoso sotto le coperte. Non usano una sorta di codice di identificazione universale per ogni persona?
"La mossa intelligente sarebbe quella di creare un identificatore univoco universale (UUID), archiviare valori crittografati - nota plurale - di quelle che potrebbero essere informazioni uniche (SSN, DOB, età, biometria) e quindi valutarle per prove di personalità unica", Disse Malafsky.
Il fatto che qualcuno possa ricevere i documenti riservati di una persona diversa è indicibilmente negativo e dimostra alcuni seri problemi di mappatura nel profondo della bestia. - Eleggibilità
OK gente. Ecco dove la vita diventa interessante! Se ormai la tua transazione non è scaduta, quasi sicuramente ha funzionato in questo passaggio. Secondo il grafico del Washington Post, "Il sistema deve determinare l'idoneità per un aiuto finanziario inviando le informazioni personali del consumatore a un hub di dati che contrae decine di agenzie federali e statali".
Cercare di eseguire una transazione su tre o quattro sistemi chiave è una vera sfida. Cercare di colpire "dozzine" di agenzie statali e federali "in tempo reale" è fuori scala e del tutto inutile. Malafsky ha preso solo un punto di interazione per presentare il suo caso:
"Uno di quelli ovvi qui è ottenere dati finanziari a persona per determinare se meritano un sussidio o quale sarebbe il loro prezzo, quindi andiamo all'IRS. Ora, abbiamo qualche link laggiù, ma quel link è attivo Ciò significa che quando l'utente è seduto lì in attesa sullo schermo del proprio computer, deve creare un collegamento ai sistemi IRS. In un mondo perfetto, quel collegamento accade, i computer parlano, ottengo il mio risultato e torno indietro.
"Che ne pensi del mondo reale? Che dire di quando i sistemi IRS sono sovraccarichi? Che ne dici di quando sono a piena capacità? Che ne dici di quando forse stanno facendo la manutenzione? Che ne è di una rete tra il centro operativo di rete del livello base? Pagina Web che il client vede al centro IRS? Forse ci sono alcuni problemi lì. Forse c'è un virus. Forse c'è un cavallo di Troia che corre in giro e le telecomunicazioni hanno chiuso le cose per risolvere quel problema. Ciò ucciderà la transazione dal punto di vista dell'utente. Questo è solo uno dei tanti punti di questo tipo di architettura ", ha affermato Malafsky.
Il suo punto è che ognuno di questi sistemi - dato che questa immagine Web è stata progettata per HealthCare.gov - ognuno di essi è un potenziale tallone d'Achille. Questa è una situazione senza vincita. E ancora, non è necessario dal punto di vista del flusso di lavoro. Esistono molti punti lungo il percorso in cui il flusso di lavoro potrebbe essere aumentato con data mart quasi in tempo reale, data marting al momento giusto, persino interventi umani per affrontare i principali punti di guasto dell'automazione.
Il grande errore strategico, quindi, stava cercando di raggiungere un sito così incredibilmente complesso. - Shopping per un piano
Ricorda: questo doveva essere il flusso del sito originale. I navigatori del web acquisterebbero prima un piano assicurativo. Quindi, quando hanno trovato qualcosa di interessante, hanno potuto registrarsi per un account, verificare i sussidi se lo desideravano e infine acquistare un piano.
Secondo il grafico, "ad alcuni individui a basso reddito viene detto che non possono beneficiare di sussidi o non possono beneficiare di Medicaid, anche se dovrebbero". La domanda qui diventa: Perché questo problema è elencato al passaggio 5 anziché al passaggio 4? Questo è un problema associato al fatto che il passaggio precedente non viene calcolato in modo appropriato e quindi non viene preso in considerazione correttamente nel passaggio 5. - Traduzione assicurativa
Nel nostro mondo, chiamiamo questa parte ETL. È un problema risolto tanto quanto la registrazione del sito.
- Iscrizione assicurativa
Il Sacro Graal! Ma aspetta, c'è un ultimo "problema tecnico", secondo gli appaltatori di HealthCare.gov: "I rapporti, noti come 834, a volte sono confusi e duplicativi, rendendo difficile per le compagnie assicurative sapere chi sono realmente i loro nuovi clienti".
Prendiamoci un momento di silenzio per apprezzare questo …
Quindi, sì, in realtà una compagnia assicurativa deve sapere chi sta veramente assicurando. Questo è un componente piuttosto critico. Lo stesso vale per un operatore d'emergenza che sa quale persona curare o per un medico che sa in quale cuore dovrebbe essere trapiantato un cuore. Nel settore dei media, potremmo caratterizzare questa piccola caratteristica come un caso dei nostri appaltatori federali che seppelliscono con successo il lede. - Copertura
Ultimo ma non meno importante, il grafico afferma che "i funzionari dell'amministrazione affermano che gli acquirenti hanno presentato più di 700.000 domande di assicurazione sanitaria. Alcuni di questi sono passati attraverso HealthCare.gov e altri attraverso i mercati statali. Ma i funzionari rifiutano di dire quante persone si sono iscritte a un Piano."
Azionamento manuale
Forse la curva più acuta lanciata nel mix proprio di recente è stata la mossa per promuovere le applicazioni cartacee a causa delle sfide della funzionalità del sito. Sfortunatamente, anche i moduli cartacei devono essere inviati al sito non funzionante. Per definizione, non si tratta di una sostituzione manuale. Per definizione, una sostituzione manuale deve consentire a qualcuno o qualcosa di scavalcare manualmente il sistema automatizzato.
E ora, al momento della pubblicazione di questo articolo, sentiamo che per il rilancio di HealthCare.gov, l'amministrazione si affida maggiormente alle compagnie assicurative per risolvere i problemi. Indovina cosa significa: scommetto che ciambelle in dollari (sì, era il contrario), che ciò che sta accadendo in questo momento è un caso di rip-and-sostituisci diffuso. In particolare, programmatori e ingegneri hanno probabilmente strappato via molte delle "connessioni in tempo reale" e altri middleware intensamente costosi che hanno entusiasmato gli editori del Washington Post. La sostituzione di tutto quel codice complesso è molto più semplice, connessioni a latenza più elevata che sono alimentate da una gamma di data mart collegati tramite più di un ambiente batch ai vari sistemi statali e federali.
In altre parole, il tipo di soluzione che Malafsky, Bloor e McAfee suggeriscono è dove stiamo andando. E tutto quel fantasioso codice di spaghetti che questi imprenditori federali hanno speso mezzo miliardo di dollari per costruire negli ultimi tre anni e mezzo? Nel contenitore degli oggetti taglienti.
Piombo sepolto
E un'ultima nota: secondo la testimonianza prima del Congresso di Henry Chao, vicedirettore delle informazioni dei Centri per i servizi Medicare e Medicaid, il sistema di pagamento che rimborserà le compagnie assicurative con tutti quei sussidi federali? Non è stato ancora costruito! Ciò significa che questo potrebbe essere solo il primo sito di e-commerce su larga scala mai lanciato senza un mezzo funzionante per il trasferimento di denaro.
