Indholdsfortegnelse:
For det første, gør ingen skade! Denne edik - parafraseret fra den Hippokratiske ed - gennemtrænger den professionelle sundhedsvæsen, som den har siden daggryet af den vestlige medicin for ca. 2.500 år siden. Enhver kan sætte pris på enkelheden og betydningen af denne mantra. Hvis du ikke gør noget andet som sundhedsperson, skal du i det mindste ikke skade din patient.
Skrevet i understrømmen af denne sætning kan du finde en ubestridelig ydmyghed. Faktisk er der for alle de forskellige og forskellige videnskabelige veje en kritisk aksiom: vær altid villig til at stille spørgsmålstegn ved dine antagelser. Vi ved kun, hvad vi ved, og vi ved bestemt ikke noget endnu, og vi vil heller aldrig nogensinde. Lad denne visdom tjene som en advarsel for dine stærkeste recept.
Så er der den del, der gør. I enhver livsindsats håber man at vide noget om import og derefter tage passende skridt. Omhyggelig er lige så omhyggelig, og når man plejer andres liv, er det nødvendigt med alvor. Med dette perspektiv som vores lærred og en forståelse af informationsteknologi (IT) under vores bælter, lad os se på udrullingen af HealthCare.gov, det ofte karakteriserede flagskib i Affordable Care Act, også kaldet "Obamacare."
Livsstøtte
Hvor sløv kan jeg være? HealthCare.gov var død ved ankomsten. Den kollektive gennemsigtighed siger nu, at alle seks personer tilmeldte sig den første dag, den 1. oktober. Seks. Kun 32.994 mangler det 33.000 daglige mål. Og mens "kapacitets" -spørgsmål blev anerkendt som backhanded anerkendelser af efterspørgsel, vidste enhver med viden om webdynamik bedre.
"Dette er ikke et uløst problem, " bemærker Dr. Robin Bloor, en dataforsker og medstifter af The Bloor Group. "Holland har en sådan udveksling."
Faktisk har hollænderne været foran spillet i to årtier nu med mange erfaringer. Schweizerne har også en del erfaring, og Massachusetts har selvfølgelig MAHealthConnector.org, såkaldt "RomneyCare."
Bloor fortsatte med at sige, at 40 års it-erfaring har bevist, at store projekter altid bærer en stor risiko.
"Lav et stort projekt, høj risiko for høj risiko for fiasko. At have tre og et halvt år lyder som i en moderne tid, det ville være nok, men her er et højrisikoprojekt, og det hele viste sig dårligt, ”Sagde Bloor.
Han var mest oprigtig over den måde, hvorpå integrationstest blev udført for HealthCare.gov.
"Den sidste ting, der gjorde mig, næsten fik mig til at grine med grin, er ingen integrationstest før to uger før du går live - og det er ligesom, hvordan kunne du nogensinde gøre det med noget lignende? Hvordan kunne du det?" Bloor sagde.
Deler dette perspektiv er en veteran føderal entreprenør og stipendiat dataforsker, Dr. Geoffrey Malafsky fra Phasic Systems Inc. Malafsky tilbød for nylig en times lang, detaljeret vurdering af HeathCare.govs udrulning og kommenterede både de strategiske og taktiske beslutninger, der blev taget . Frem for alt peger han fingeren på forbundsregeringens erhvervelsesprotokol.
"Et af de kritiske svigtpunkter, der gennemsyrer især regerings-it-projekter, er denne arv, arkaiske, forældede opfattelse af, at du kan artikulere al den nødvendige forretningslogik med nogle lineære kravsprocesser. Det grundlæggende fungerer ikke med store it-systemer, " sagde han.
Hans pointe er, at store it-systemer vil bedevilge selv de smarteste planlæggere. Du ved bare aldrig, hvor der kommer problemer, hvor du bliver nødt til at yde ekstra support, eller hvilken slags fejlfinding du finder dig selv engageret i. Derfor er det en dårlig ide at begrænse designprocessen ved at tvinge projektingeniører til at foregribe alt de har brug for på forhånd.
Komplicerende sager, siger Malafsky, er det faktum, at indkøbstjenestemænd i den føderale regering nu er blevet så magtfulde - på grund af de enorme mængder penge, de kontrollerer - at de i det væsentlige har kontrol over, hvordan store it-projekter går fremad. Dette sætter afdelingens embedsmænd i rollen som supplicant og indsætter et element af risiko i en afgørende procedure i centrum for ethvert væsentligt IT-initiativ: valg af de rigtige værktøjer, teknologier og entreprenører.
"De mennesker, der mest taler uenige med denne erklæring, kaldes erhvervelsesfolk, og jeg opfordrer dem til at dukke op i mit hus, og vi vil sidde rundt og diskutere dette, fordi jeg har en masse empiriske beviser til at støtte det, " siger Malafsky sagde.
Site strategi
Et stort spørgsmål at stille er hvorfor regeringen omfavnede en så omfattende arkitektur til dette websted.
"Hvis det overordnede regeringsprogram er oprettet således, at forsikringsselskaberne faktisk ejer klienten, efter at de har fået en forpligtelse, hvorfor hvorfor ikke bare skubbe trafikken til den eksisterende klientinteraktionsmiljøkanal, som forsikringsselskaberne allerede har? Ja, de kan måske har brug for at udvide deres egne, men det ville være en gyldig forretningsgrund, fordi de nu får nye kunder, ”sagde Malafsky.
Den verdenskendte (og nu noget berygtede) sikkerhedssoftwarepionør John McAfee kommenterede også for nylig denne strategi og fremsatte nogle kontroversielle bemærkninger til "Neil Cavuto Show" på Fox News:
”Åh, det er alvorligt dårligt, ” sagde McAfee. "Der er nogen, der begik en alvorlig fejl, ikke ved at designe programmet, men blot ved at implementere web-aspektet af det. Jeg mener, for eksempel kan enhver oprette en webside og hævde at være en mægler til dette system … enhver hacker kan placere en websted op, få det til at se ekstremt konkurrencedygtigt ud, og på grund af systemets art - og det er sundhedsvæsenet, når alt kommer til alt - kan de stille dig de mest intime spørgsmål, og du vil frit svare dem. "
Med hensyn til selve webarkitekturen peger Malafsky på det åbenlyse - at Internettet ikke var bygget til at køre komplekse applikationer. Det var jobbet med mainframe tilbage i de dage, hvor nettet var i sin spædbarn. Snarere var designpunktet for Internettet til enkel informationsdeling via individuelle sider fordelt på et bredt netværk af computere. I systemdesign er målet at opbygge noget, der fungerer. At indarbejde kompleksitet for sin egen skyld er dårligt rådgivende, ligefrem helliggørelse og næsten altid en opskrift på katastrofe.
I sit eget dybdyb om, hvad der gik galt med HealthCare.gov, offentliggjorde The Washington Post en nu berømt grafik, der skildrede de forskellige udfordringer, som stedet oplever. Det sprog, som papiret bruger til at beskrive stedet, er faktisk ret afslørende, især når du overvejer, at dette er den etablerede avis i Washington, DC, episenteret for den amerikanske føderale regering:
HealthCare.gov, bygget af 55 entreprenører, er en af de mest komplekse stykker software, der nogensinde er skabt til den føderale regering. Det kommunikerer i realtid med mindst 112 forskellige computersystemer i hele landet. I løbet af de første 10 dage modtog den 14, 6 millioner unikke besøg, ifølge Obama-administrationen.
Kilde: The Washington Post
Det kan sandsynligvis, pr. Definition, at nogen hævder, at de har et stykke software, det skal være tilfældet, at softwaren faktisk fungerer. Ellers har du en samling af kode, der endnu ikke udgør et stykke software. Dette småtteri til side, skal du bemærke de anførte numre, især delen om at kommunikere "i realtid" med 112 forskellige computersystemer rundt om i landet. Dette er et perfekt eksempel på at glorificere kompleksiteten for sin egen skyld.
"Vi ved, at en anden mulighed er at have oprettet et enkelt, meget simpelt webmæglingssystem, at alt det gør er ved meget simpel appserverkode og endnu enklere klientside Javascript, skaber en meget behagelig grænseflade, der producerer sammenrullede data til folk, "Sagde Malafsky. "Her er hvad du kan gøre: gå igennem dette; gå igennem dette. Så kan enhver handling, der finder sted, udføres på udvælgelsespunkt og sendes til nogen, der rent faktisk vil eje programmet." Naturligvis henviser denne "nogen" til de forsikringsselskaber, der alligevel vil eje forsikringerne.
Den grafiske grafik
Systemdesignere overalt i verden må have krøllet sig efter at se den grafik. Lad os se på de forskellige skridt, der er skitseret, og især de alvorlige problemer, der opstår med en så ambitiøs arkitektur. Først og fremmest overvejer vi antallet af potentielle transaktioner, der hidtil er mislykkedes, de fleste af dem på grund af softwaretimeout - tilfælde, hvor en del af transaktionsprocessen ikke modtager de nødvendige data inden for en acceptabel tidsperiode.
"Hvert enkelt stykke software i den grafik havde sine egne timeouts, og det er ikke engang en timeout. Det kan være mere, " sagde Malafsy. "Udløbet af en af dem vil dræbe hele transaktionen. Nogle af dem er lette at konfigurere og overvåge, ligesom logfiler. De er som timeouts på webserveren og appserveren. Nogle er mere uigennemsigtige. Du har databaser med samtidighed og triggere, men de er multi-interaktion. Hvis du virkelig går dybt ned i, hvordan databaser fungerer, er det ikke et smukt syn. " (Lær det grundlæggende om, hvordan databaser fungerer i vores Tutorials til databaser.)
"Dataserverne elsker at sige, 'Vi holder alt ordentligt.' Ikke rigtig, "sagde Malafsky. Den eneste måde, hvorpå de kan få ydeevnen op og virkelig styre det, er, at der er en række tidsstemplede filer, der oprettes på lageret, vedvarende lagring, og de rulles ikke op til en omfattende nøjagtigt datasæt, der er til rådighed for enhver tid, fordi det tager for lang tid.Det ville dræbe den transaktionsmæssige latenstid. Du er nødt til at kigge ind i disse detaljer, og så rulles den op gennem en administrationsgrænseflade - og det går af nogle meget rart sofistikeret navne som triggere og samtidighed - men det betyder dybest set, at det tager en masse tid at hente dataene, opdatere dataene, og hvis jeg ikke kan gøre det, før en anden anmodning kommer ind, vil jeg bare fortælle dig, ' Glem det. Jeg er lukket for forretning. '"
- "Fordøren"
Washington Posts grafik indeholder et meget nysgerrig stykke information lige ved tippy-toppen i dets første "problem" -sektion, hvor det siger, at "Obama-administrationen besluttede i slutningen af september for nu at udelukke en funktion, der ville have ladet folk handle efter sundhedsplaner uden først at oprette en online konto. "
Wow. Først og fremmest, er det virkelig en "funktion", der blev udelukket? Vi taler om grundlæggende webstedsstrøm. Oprindeligt var planen at lade folk shoppe rundt og derefter overveje at registrere en konto på det passende tidspunkt.
Nogle kritikere har spekuleret i, at denne ændring i sidste øjeblik (i sig selv et utroligt risikabelt træk med et stort projekt), viser, at administrationen vidste, at webstedet ikke fungerede godt i de sidste par uger frem til 1. oktober-lanceringen . I stedet blev ideen at fange alle oplysninger fra dem, der havde brug for forsikring, således at der kunne gøres en markedsføringsindsats et sted nede på linjen, når webstedet var funktionelt.
Fra et brugervenligheds- og kapacitetsperspektiv, satte dette skridt i sidste øjeblik en enorm belastning på det databasefundament, webstedet havde. Dette forklarer alle anekdoter om, at folk ikke kan registrere eller bliver tvunget til at ændre deres adgangskoder. Og lad os være ærlige her. Er der noget problem, der mere grundigt løses overalt på internettet end processen med at oprette en brugerkonto? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - endda din bedstemors strikningsklasse - har sin egen dynamiske tilmeldingsform i disse dage med indbakket afmelding, frem og andre grundlæggende funktioner. - Registrering
Da det var tid til at registrere sig på HealthCare.gov, siger entreprenørerne, "Kommunikationen mellem nogle af disse systemer fungerede ikke korrekt, hvilket betyder, at mange brugere ikke var i stand til at oprette en konto."
Hvad? Hvilke systemer? Vi taler om en kundedatabase! "Systemerne" ville derefter være webklienten og kundedatabasen. Hvilke andre systemer var involveret? Denne særlige "forklaring" giver ingen mening. - Identitets bevis
Næste op, bevis på identitet. For dette trin er der ikke nævnt nogen problemer, hvilket også er nysgerrig. Experian er angivet som den tredjepartsagent, der "verificerer" noens identitet. Uden tvivl er identitetsløsning et alvorligt spørgsmål, der skal løses. De fleste forsikringsselskaber bruger dit personnummer, såvel som tredjepartsleverandører som Experian. Er der virkelig ingen problemer med dette trin?
Vi ved med sikkerhed fra adskillige anekdoter, verificeret ved fremlagt dokumentation, at HealthCare.gov helt sikkert har oplevet fortrolige informationer. Malafsky påpeger, at datakvalitetsproblemerne er de langt mere alvorlige end kapacitetsproblemerne. (Og Bloor bemærker, at hvis kapacitetsproblemer virkelig var problemerne, skulle de have været løst i dage, ikke uger. Du kan tilføje hardware, virtualisere, gøre et hvilket som helst antal ting til kapacitetsproblemer.)
Nej, spørgsmålene om datakvalitet er de virkelig farlige. Og det mest bekymrende aspekt af det hele er de slags datakvalitetsproblemer, der er opstået. Der er historier om folk, der tilmelder sig og derefter modtager fortrolige kvalificeringsdokumenter, der tilhører andre registranter! Dette lugter af et absolut frygteligt design under dækslerne. Bruger de ikke en slags universel identifikationskode til hver person?
"Det smarte træk ville være at oprette en universelt unik identifikator (UUID), gemme krypterede værdier - bemærk flertal - af hvad der kan være unik information (SSN, DOB, alder, biometri) og derefter vurdere disse for bevis på unik personlighed, " Sagde Malafsky.
At nogen kunne modtage en anden persons fortrolige dokumenter er ubeskriveligt dårlig, og demonstrerer nogle meget alvorlige kortlægningsproblemer dybt inde i udyrets mave. - Berettigelse
OK, folkens. Her bliver livet interessant! Hvis din transaktion ikke var udløbet i øjeblikket, gjorde den næsten helt sikkert på dette trin. I henhold til The Washington Posts grafik, "Systemet skal bestemme støtteberettigelse til økonomisk hjælp ved at sende forbrugerens personlige oplysninger til en Data Hub, der kontraherer snesevis af føderale og statslige agenturer."
At prøve at udføre en transaktion på tværs af tre eller fire nøglesystemer er en ægte udfordring. At forsøge at ramme "snesevis" af statslige og føderale agenturer "i realtid" er uden for kortene og helt unødvendigt. Malafsky tog kun et samspilspunkt for at gøre sin sag:
"En af de åbenlyse her er at få økonomiske data pr. Person til at bestemme, om de fortjener et tilskud eller hvad deres prispoint ville være, så vi går videre til IRS. Nu har vi et link derovre, men det link er live Det betyder, at når brugeren sidder der og venter ved deres computerskærm, er det nødt til at skabe et link til IRS-systemerne. I en perfekt verden sker det link, computere taler, jeg får mit resultat, og jeg kommer tilbage.
"Hvad med i den virkelige verden? Hvad med når IRS-systemerne er overbelastede? Hvad med når de er i kapacitet? Hvad med når de måske vedligeholder? Hvad med det er et netværk mellem netværksoperationscenteret på entry-level Web-side, som klienten ser til IRS-centret? Måske er der nogle problemer der. Måske er der en virus. Måske er der en trojansk hest, der løber rundt, og telekommunikationerne har lukket tingene for at løse det problem. Det vil dræbe transaktionen fra det punkt syn på brugeren. Det er kun et af mange sådanne punkter i denne arkitektur, ”sagde Malafsky.
Hans pointe er, at hvert eneste af disse systemer - som denne webarkitektur blev designet til HealthCare.gov - hver og en af dem er en potentiel akilleshæl. Det er en no-win situation. Og igen er det unødvendigt set fra et arbejdsgangsperspektiv. Der er et vilkårligt antal punkter undervejs, hvor arbejdsgangen kan udvides med næsten realtid-datamars, datamars til højre tid, endda menneskelig indgriben til at tackle de vigtigste fejlpunkter i automatisering.
Den store strategiske fejl var derfor at forsøge at opnå et så utroligt komplekst websted. - Shopping efter en plan
Husk: Dette skulle være den originale webstedsstrøm. Websurfere skulle først købe en forsikringsplan. Når de så fandt noget af interesse, kunne de registrere sig for en konto, se efter subsidier, hvis de ønskede det, og i sidste ende købe en plan.
I henhold til grafikken siges, at "nogle personer med lave indkomster får at vide, at de ikke er berettigede til subsidier eller ikke kvalificerer sig til Medicaid, selvom de skulle." Spørgsmålet her bliver: Hvorfor er dette problem opført under trin 5 i stedet for trin 4? Dette er et problem, der er forbundet med, at det forrige trin ikke beregnes korrekt, og at det således ikke indgår korrekt i trin 5. - Oversættelse til forsikring
I vores verden kalder vi denne del ETL. Det er lige så løst et problem som webstedsregistrering.
- Tilmelding til forsikring
Den hellige gral! Men vent, der er en sidste "fejl", ifølge HealthCare.govs entreprenører: "Rapporterne, kendt som 834s, er undertiden forvirrende og duplikative, hvilket gør det vanskeligt for forsikringsselskaberne at vide, hvem deres nye kunder virkelig er."
Lad os tage et øjeblik af stilhed for at værdsætte denne…
Så ja, faktisk skal et forsikringsselskab vide, hvem det virkelig forsikrer. Det er en ret kritisk komponent. Det samme gælder en akutmedarbejder, der ved, hvilken person han skal behandle, eller en læge, der ved, i hvilket bryst et hjerte skal transplanteres. I mediebranchen karakteriserer vi måske denne lille sag som et tilfælde af, at vores føderale entreprenører ganske vellykket begraver folken. - Dækning
Sidst men ikke mindst angiver grafikken, at "administrationsembedsmænd siger, at kunder har indgivet mere end 700.000 sundhedsforsikringsansøgninger. Nogle af dem er kommet gennem HealthCare.gov og andre gennem statslige markedspladser. Men embedsmænd nægter at sige, hvor mange mennesker, der har tilmeldt sig en plan."
Manuel tilsidesættelse
Måske den skarpeste kurvebold, der blev kastet i blandingen for nylig, var skridtet til at promovere papirapplikationer på grund af webstedets funktionsudfordringer. Desværre skal selv papirformularerne indsendes til det ikke-fungerende sted. Per definition er det ikke en manuel tilsidesættelse. Per definition skal en manuel tilsidesættelse give nogen eller noget mulighed for manuelt at tilsidesætte det automatiserede system.
Og nu, på tidspunktet for offentliggørelsen af denne artikel, hører vi, at administrationen i forbindelse med relanceringen af HealthCare.gov i højere grad er afhængig af forsikringsselskaber til at løse problemerne. Gæt hvad det betyder - jeg vil satse dig donuts til dollars (ja, det plejede at være omvendt), at hvad der sker lige nu er et tilfælde af udbredt rip-and-erstatning. Specifikt har programmerere og ingeniører sandsynligvis flået mange af "realtidsforbindelserne" og andre intenst dyre mellemvarer, der fik Washington Post's redaktører så begejstrede. Udskiftning af al den komplekse kode er meget enklere forbindelser med højere latenstid, der mates af en række datamarkter, der er forbundet via mere af et batch-miljø til de forskellige statslige og føderale systemer.
Med andre ord, den slags løsning, Malafsky, Bloor og McAfee foreslår, er, hvor vi skal hen. Og al den smarte spaghettikode, som disse føderale entreprenører brugte en halv milliard dollars bygning i de sidste tre og et halvt år? I skarpe beholderen.
Begravet bly
Og en sidste note: I henhold til vidnesbyrd før kongres fra Henry Chao, Centers for Medicare og Medicaid Services viceadministrerende informationschef, betalingssystemet, der refunderer forsikringsselskaber med alle disse føderale subsidier? Det er ikke bygget endnu! Det betyder, at dette muligvis bare er det første store e-handelswebsted, der nogensinde er lanceret uden et fungerende middel til at overføre penge.
