Inhoudsopgave:
Ten eerste, doe geen kwaad! Dat edict - geparafraseerd uit de eed van Hippocrates - doordringt professionele gezondheidszorg, zoals het sinds het begin van de westerse geneeskunde zo'n 2500 jaar geleden is. Iedereen kan de eenvoud en betekenis van deze mantra waarderen. Als u niets anders doet als arts, doet u uw patiënt tenminste geen pijn.
Geschreven in de onderstroom van die zin, kun je een onmiskenbare nederigheid vinden. In feite is er voor alle verschillende wegen van de wetenschap een kritisch axioma: wees altijd bereid je aannames in twijfel te trekken. We weten alleen wat we weten, en we weten zeker nog niet alles, en dat zullen we ook nooit weten. Laat die wijsheid dienen als een waarschuwing voor uw sterkste recepten.
Dan is er het doen deel. Bij elk levensdoel hoopt men iets van belang te weten en vervolgens passende maatregelen te nemen. Voorzichtig is net zo voorzichtig, en als men voor het leven van anderen zorgt, is ernst vereist. Met dit perspectief als ons canvas, en een begrip van informatietechnologie (IT) onder onze riem, laten we eens kijken naar de uitrol van HealthCare.gov, het vaak kenmerkende vlaggenschip van de Affordable Care Act, ook bekend als "Obamacare".
Levensondersteuning
Hoe bot kan ik zijn? HealthCare.gov was dood bij aankomst. De collectieve transparantie zegt nu dat alle zes mensen zich op de eerste dag, 1 oktober, hadden aangemeld. Zes. Slechts 32, 994 te kort van het 33.000 dagelijkse doel. En terwijl problemen met de "capaciteit" aangeprezen werden als backhanded lofbetuigingen van de vraag, wist iedereen met kennis van webdynamiek beter.
"Dit is geen onopgelost probleem", merkt Dr. Robin Bloor op, datawetenschapper en mede-oprichter van The Bloor Group. "Nederland heeft zo'n uitwisseling."
Nederlanders lopen al twee decennia voor op het spel, met veel lessen die zijn geleerd. De Zwitsers hebben ook enige ervaring, en natuurlijk heeft Massachusetts MAHealthConnector.org, de zogenaamde "RomneyCare".
Bloor zei verder dat 40 jaar IT-ervaring heeft bewezen dat grote projecten altijd een groot risico inhouden.
"Doe een groot project, hoog risico hoog faalrisico. Drie en een half jaar klinken klinkt als in een moderne dag, dat zou genoeg zijn, maar hier is een project met een hoog risico en het is allemaal slecht gebleken, "Bloor zei.
Hij was zeer openhartig over de manier waarop integratietests werden uitgevoerd voor HealthCare.gov.
"Het laatste ding dat me bijna deed lachen, is geen integratietest tot twee weken voordat je live gaat - en dat is net zoals, hoe zou je dat ooit kunnen doen met zoiets? Hoe zou je?" Zei Bloor.
Het delen van dat perspectief is een ervaren federale aannemer en collega-datawetenschapper, Dr. Geoffrey Malafsky van Phasic Systems Inc. Malafsky bood onlangs een urenlange, gedetailleerde beoordeling van de uitrol van HeathCare.gov en becommentarieerde zowel de strategische als tactische beslissingen die werden genomen . Boven alles wijst hij op het acquisitieprotocol van de federale overheid.
"Een van de kritieke faalpunten die vooral IT-projecten van de overheid doordringen, is deze oude, archaïsche, verouderde notie dat je met een lineair vereistenproces alle noodzakelijke bedrijfslogica kunt verwoorden. Dat werkt fundamenteel niet met grote IT-systemen, " zei hij.
Zijn punt is dat grote IT-systemen zelfs de slimste planners zullen bederven. Je weet nooit waar problemen zullen komen, waar je extra ondersteuning moet bieden, of wat voor soort probleemoplossing je moet uitvoeren. Daarom is het een slecht idee om het ontwerpproces te beperken door projectingenieurs te dwingen op alles te anticiperen ze hebben vooraf nodig.
Complicerende zaken, zegt Malafsky, zijn het feit dat inkoopfunctionarissen in de federale overheid nu zo krachtig zijn geworden - vanwege de enorme hoeveelheden geld die ze beheren - dat ze in wezen controle hebben over hoe grote IT-projecten verder gaan. Dit plaatst afdelingsambtenaren in de rol van aanvrager en voegt een element van risico in een cruciale procedure centraal in elk belangrijk IT-initiatief: het kiezen van de juiste tools, technologieën en aannemers.
"De mensen die het meest luidruchtig oneens zijn met die verklaring, worden acquisitieprofessionals genoemd, en ik moedig ze aan om bij mij thuis te verschijnen en we zullen hier rondhangen en debatteren, omdat ik veel empirisch bewijs heb om dat te ondersteunen, " Malafsky zei.
Sitestrategie
Een grote vraag die moet worden gesteld, is waarom de overheid zo'n uitgebreide architectuur voor deze website omarmde.
"Als het overkoepelende overheidsprogramma zodanig is opgezet dat de verzekeringsmaatschappijen de klant daadwerkelijk bezitten nadat ze een verbintenis hebben gekregen, waarom dan niet gewoon het verkeer doorsturen naar het bestaande klantinteractiekanaal dat de verzekeringsmaatschappijen al hebben? Ja, ze kunnen nodig hebben om hun eigen te vergroten, maar dat zou een geldige zakelijke reden zijn omdat ze nu nieuwe klanten gaan krijgen, "zei Malafsky.
De wereldberoemde (en nu enigszins beruchte) pionier op het gebied van beveiligingssoftware John McAfee gaf onlangs ook commentaar op deze strategie en maakte enkele controversiële opmerkingen over de "Neil Cavuto Show" op Fox News:
"Oh, het is serieus slecht, " zei McAfee. "Iemand heeft een ernstige fout gemaakt, niet bij het ontwerpen van het programma, maar bij het simpelweg implementeren van het webaspect ervan. Ik bedoel, bijvoorbeeld, iedereen kan een webpagina opzetten en claimen een makelaar voor dit systeem te zijn … elke hacker kan een website omhoog, waardoor het er extreem competitief uitziet, en vanwege de aard van het systeem - en dit is tenslotte gezondheidszorg - kunnen ze u de meest intieme vragen stellen, en u kunt ze vrijelijk beantwoorden. "
Met betrekking tot de webarchitectuur zelf, wijst Malafsky op het voor de hand liggende - dat het internet niet is gebouwd om complexe applicaties te draaien. Dat was de taak van het mainframe in de tijd dat internet nog in de kinderschoenen stond. Het ontwerppunt voor internet was eerder het eenvoudig delen van informatie via afzonderlijke pagina's die over een breed netwerk van computers werden verspreid. Bij het ontwerpen van systemen is het doel om iets te bouwen dat werkt. Het opnemen van complexiteit omwille van zichzelf is slecht geadviseerd, ronduit heiligschennis en bijna altijd een recept voor een ramp.
In zijn eigen diepe duik over wat er mis ging met HealthCare.gov, publiceerde The Washington Post een nu beroemde afbeelding die de verschillende uitdagingen van de site afbeeldde. De taal die door de krant wordt gebruikt om de site te beschrijven is eigenlijk vrij onthullend, vooral als je bedenkt dat dit de gevestigde krant is van Washington, DC, het epicentrum van de Amerikaanse federale overheid:
HealthCare.gov, gebouwd door 55 aannemers, is een van de meest complexe stukjes software die ooit voor de federale overheid is gemaakt. Het communiceert in realtime met minstens 112 verschillende computersystemen in het hele land. In de eerste 10 dagen ontving het volgens de regering-Obama 14, 6 miljoen unieke bezoeken.
Bron: The Washington Post
Als iemand per definitie beweert dat hij een stuk software heeft, moet het betwistbaar zijn dat de software daadwerkelijk werkt. Anders heb je een compilatie van code die nog geen stukje software vormt. Los dat beetje op, let op de vermelde nummers, vooral het gedeelte over "realtime" communiceren met 112 verschillende computersystemen in het hele land. Dit is een perfect voorbeeld van het verheerlijken van complexiteit omwille van zichzelf.
"We weten dat een andere mogelijkheid is om een eenvoudig, zeer eenvoudig webmakelaarssysteem te hebben gemaakt, dat het enige is door een zeer eenvoudige app-servercode en nog eenvoudiger client-side Javascript, een zeer aangename interface creëert die samengevatte gegevens voor mensen produceert, "Zei Malafsky. "Hier is wat je kunt doen: stap door dit; stap door dit. Dan kan elke actie die zich voordoet op het selectiepunt worden gedaan en worden verzonden naar iemand die daadwerkelijk het programma gaat bezitten." Natuurlijk verwijst die "iemand" naar de verzekeringsmaatschappijen die hoe dan ook de polissen bezitten.
De grafische afbeelding
Systeemontwerpers van over de hele wereld moeten bij het zien van die afbeelding zijn toegetreden. Laten we eens kijken naar de verschillende stappen die worden beschreven, en in het bijzonder, de ernstige problemen die zich voordoen met zo'n ambitieuze architectuur. Eerst en vooral zullen we het aantal potentiële transacties beschouwen dat tot nu toe is mislukt, de meeste vanwege softwaretime-outs - gevallen waarin een deel van het transactieproces de benodigde gegevens niet binnen een acceptabele periode ontvangt.
"Elk stukje software in die afbeelding had zijn eigen time-outs, en het is niet eens een time-out. Het kan meer zijn, " zei Malafsy. "Het vervallen van een van deze zal de hele transactie doden. Sommige daarvan zijn eenvoudig in te stellen en te bewaken, zoals logbestanden. Die zijn als de time-outs op de webserver en de app-server. Sommige zijn ondoorzichtiger. Je hebt databases met concurrency en triggers, maar ze zijn multi-interactie. Als je echt een diepe duik neemt in hoe databases werken, is het geen mooi gezicht. " (Leer de basisprincipes van hoe databases werken in onze Databases-zelfstudie.)
"De databaseservers zeggen graag: 'We houden alles overzichtelijk.' Niet echt, "zei Malafsky. De enige manier waarop ze de prestaties kunnen verbeteren en echt kunnen beheren, is dat er een reeks tijdgestempelde bestanden op de opslag zijn gemaakt, permanente opslag, en ze zijn niet samengevoegd uitgebreide, nauwkeurige set gegevens die voor iedereen op elk moment beschikbaar is, omdat dat te lang duurt. Dat zou de transactionele latentie doden. Je moet in die details kijken en dat wordt vervolgens opgerold via een beheerinterface - en dat gaat een aantal zeer mooie geavanceerde namen zoals triggers en gelijktijdigheid - maar het betekent in feite dat het een hoop tijd kost om de gegevens op te halen, de gegevens bij te werken, en als ik het niet kan doen voordat er een ander verzoek binnenkomt, ga ik je gewoon vertellen, ' Vergeet het maar. Ik ben gesloten voor zaken. ''
- "De voordeur"
De afbeelding van de Washington Post bevat een zeer merkwaardig stuk informatie direct bij de top in zijn eerste 'probleem'-gedeelte, waar staat dat' de regering-Obama eind september besloot om een functie uit te sluiten die mensen zou laten winkelen voor gezondheidsplannen zonder eerst een online account aan te maken. "
Wauw. Allereerst, is dat echt een "functie" die werd uitgesloten? We hebben het over de fundamentele sitestroom. Oorspronkelijk was het plan om mensen rond te laten shoppen en vervolgens op het juiste moment te overwegen een account te registreren.
Sommige critici hebben gespeculeerd dat deze last-minute verandering (en op zichzelf een ongelooflijk risicovolle stap met een project zo groot), laat zien dat de administratie wist dat de site niet goed werkte in de laatste paar weken voorafgaand aan de lancering van 1 oktober . In plaats daarvan werd het idee om alle informatie vast te leggen van diegenen die een verzekering nodig hadden, zodat marketinginspanningen konden worden ondernomen zodra de site functioneel was.
Vanuit het oogpunt van bruikbaarheid en capaciteit heeft deze last-minute beweging een enorme druk uitgeoefend op de databasebasis die de site had. Dit verklaart alle anekdotes van mensen die zich niet kunnen registreren of gedwongen worden om hun wachtwoord te wijzigen. En laten we hier eerlijk zijn. Is er een probleem dat grondiger op het hele internet is opgelost dan bij het opzetten van een gebruikersaccount? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - zelfs de breiklasse van je grootmoeder - heeft tegenwoordig zijn eigen dynamische aanmeldingsvorm, met ingebouwde uitschrijving, doorsturen en andere fundamentele functies. - registratie
Toen het tijd was om te registreren op HealthCare.gov, zeggen de aannemers: "De communicatie tussen sommige van deze systemen werkte niet goed, wat betekent dat veel gebruikers niet in staat waren om met succes een account aan te maken."
Wat? Welke systemen? We hebben het over een klantendatabase! De "systemen" zouden dan de webclient en de klantendatabase zijn. Om welke andere systemen ging het? Deze specifieke "verklaring" heeft geen zin. - Identiteitsbewijs
Vervolgens het bewijs van identiteit. Voor deze stap worden geen problemen vermeld, wat ook nieuwsgierig is. Experian wordt vermeld als de externe agent die iemands identiteit "verifieert". Ongetwijfeld is identiteitsoplossing een serieus probleem dat moet worden aangepakt. De meeste verzekeringsmaatschappijen gebruiken uw sofi-nummer, evenals externe leveranciers zoals Experian. Zijn er echt geen problemen met deze stap?
Uit talloze anekdotes, geverifieerd door de gepresenteerde documentatie, weten we zeker dat HealthCare.gov zeker een achterstand van vertrouwelijke informatie heeft ervaren. Malafsky wijst erop dat de problemen met de gegevenskwaliteit veel ernstiger zijn dan de capaciteitsproblemen. (En Bloor merkt op dat als capaciteitsproblemen echt de problemen waren, deze in dagen, niet in weken hadden moeten zijn opgelost. Je kunt hardware toevoegen, virtualiseren en een aantal dingen doen voor capaciteitsproblemen.)
Nee, de problemen met de gegevenskwaliteit zijn echt gevaarlijk. En het meest verontrustende aspect van alles zijn de soorten problemen met de gegevenskwaliteit die zijn gerezen. Er zijn verhalen over mensen die zich aanmelden en vervolgens vertrouwelijke toelatingsdocumenten van andere registranten ontvangen! Dit heeft een absoluut vreselijk ontwerp onder de dekens. Gebruiken ze niet een soort universele identificatiecode voor elke persoon?
"De slimme zet zou zijn om een universeel unieke identificatie (UUID) te creëren, gecodeerde waarden op te slaan - let op het meervoud - van wat mogelijk unieke informatie is (SSN, DOB, leeftijd, biometrie) en deze vervolgens te beoordelen op bewijs van unieke persoonlijkheid, " Zei Malafsky.
Dat iemand de vertrouwelijke documenten van een andere persoon zou kunnen ontvangen, is onuitsprekelijk slecht en toont enkele zeer ernstige problemen met het in kaart brengen diep in de buik van het beest. - verkiesbaarheid
Oké, mensen. Hier wordt het leven interessant! Als er nu geen time-out voor uw transactie was opgetreden, was dit vrijwel zeker het geval bij deze stap. Volgens de afbeelding van The Washington Post: "Het systeem moet bepalen of het in aanmerking komt voor financiële hulp door de persoonlijke informatie van de consument te sturen naar een Data Hub die tientallen federale en nationale instanties contracteert."
Een transactie proberen uit te voeren over drie of vier belangrijke systemen is een echte uitdaging. Proberen om "tientallen" staats- en federale agentschappen "in real time" te raken is uit de hitlijsten en volkomen overbodig. Malafsky nam slechts één interactiepunt om zijn zaak te verdedigen:
"Een van de meest voor de hand liggende is hier het verkrijgen van financiële gegevens per persoon om te bepalen of ze een subsidie verdienen of wat hun prijs is, dus gaan we naar de IRS. Nu hebben we een link daar, maar die link is live Dat betekent dat terwijl de gebruiker daar op zijn computerscherm zit te wachten, dat een link moet maken naar de IRS-systemen. In een perfecte wereld gebeurt die link, de computers praten, ik krijg mijn resultaat en ik kom terug.
"Hoe zit het in de echte wereld? Hoe zit het wanneer de IRS-systemen overbelast zijn? Hoe zit het wanneer ze op capaciteit zijn? Hoe zit het wanneer ze misschien onderhoud aan het doen zijn? Hoe zit het met een netwerk tussen het netwerkbesturingscentrum van het instapniveau Webpagina die de client naar het IRS-centrum brengt? Misschien zijn er daar problemen. Misschien is er een virus. Misschien loopt er een Trojaans paard rond en hebben de telecombedrijven dingen afgesloten om dat probleem op te lossen. beeld van de gebruiker. Dat is slechts een van de vele punten in deze architectuur, "zei Malafsky.
Zijn punt is dat elk van deze systemen - aangezien deze webarchitectuur is ontworpen voor HealthCare.gov - elk van hen een potentiële achilleshiel is. Dat is een situatie zonder winst. En nogmaals, het is onnodig vanuit een workflowperspectief. Er is een willekeurig aantal punten onderweg waarop de workflow kan worden uitgebreid met bijna realtime datamarts, juiste datamarts en zelfs menselijke interventie om de belangrijkste faalpunten van automatisering aan te pakken.
De grote strategische fout was daarom het proberen om zo'n ongelooflijk complexe site te bereiken. - Winkelen voor een plan
Onthoud: dit was de oorspronkelijke sitestroom. Websurfers zouden eerst een verzekeringsplan kopen. Toen ze iets interessants vonden, konden ze zich registreren voor een account, op subsidies zoeken als ze dat wilden en uiteindelijk een plan kopen.
Volgens de afbeelding "wordt aan sommige personen met een laag inkomen verteld dat ze niet in aanmerking komen voor subsidies of niet in aanmerking komen voor Medicaid, hoewel ze dat wel zouden moeten doen." De vraag wordt hier: Waarom wordt dit probleem vermeld onder Stap 5 in plaats van Stap 4? Dit is een probleem dat te maken heeft met het feit dat de vorige stap niet op de juiste manier is berekend en dus niet correct is verwerkt in stap 5. - Verzekeringsvertaling
In onze wereld noemen we dit deel ETL. Het is net zo goed een probleem opgelost als siteregistratie.
- Inschrijving verzekering
De Heilige graal! Maar wacht, er is nog een laatste "glitch", volgens de aannemers van HealthCare.gov: "De rapporten, bekend als 834's, zijn soms verwarrend en dubbel, waardoor het voor verzekeringsmaatschappijen moeilijk is om te weten wie hun nieuwe klanten echt zijn."
Laten we een moment van stilte nemen om deze te waarderen …
Dus ja, in feite moet een verzekeringsmaatschappij weten wie ze echt verzekert. Dat is een nogal kritische component. Hetzelfde geldt voor een hulpverlener die weet welke persoon hij moet behandelen, of een arts die weet in wiens borst een hart moet worden getransplanteerd. In de mediasector zouden we deze kleine knaller kunnen typeren als een geval waarin onze federale aannemers de lede behoorlijk succesvol begraven. - Dekking
Last but not least staat in de grafische weergave dat 'overheidsfunctionarissen zeggen dat shoppers meer dan 700.000 aanvragen voor ziektekostenverzekeringen hebben ingediend. Sommigen van hen zijn via HealthCare.gov gekomen en anderen via staatsmarktplaatsen. Maar ambtenaren weigeren te zeggen hoeveel mensen zich hebben ingeschreven voor een plan."
Handmatig negeren
Misschien was de scherpste curveball die onlangs in de mix werd gegooid, de beweging om papieren toepassingen te promoten vanwege de functionaliteitsproblemen van de site. Helaas moeten zelfs de papieren formulieren op de niet-werkende site worden ingediend. Dat is per definitie geen handmatige opheffing. Bij een handmatige opheffing moet iemand of iets per definitie het geautomatiseerde systeem handmatig kunnen opheffen.
En nu, op het moment dat dit artikel wordt gepubliceerd, horen we dat voor de herlancering van HealthCare.gov de administratie meer afhankelijk is van verzekeringsmaatschappijen om de problemen op te lossen. Raad eens wat dat betekent - ik wed dat je donuts in dollars (ja, vroeger was het andersom), dat wat er nu gebeurt is een geval van wijdverspreide rip-and-vervangen. Specifiek hebben programmeurs en technici waarschijnlijk veel van de "realtime-verbindingen" en andere zeer dure middleware eruit gehaald die de redacteuren van de Washington Post zo enthousiast maakten. Het vervangen van al die complexe code zijn veel eenvoudiger verbindingen met een hogere latentie die worden gevoed door een reeks datamarts die via een meer batchomgeving zijn gekoppeld aan de verschillende nationale en federale systemen.
Met andere woorden, het soort oplossing dat Malafsky, Bloor en McAfee suggereren, is waar we naartoe gaan. En al die chique spaghetticode die deze federale aannemers de afgelopen drie en een half jaar hebben uitgegeven om een half miljard dollar op te bouwen? In de naaldencontainer.
Begraven lood
En nog een laatste opmerking: volgens een getuigenis voor het Congres van Henry Chao, de Centers for Medicare en Medicaid Services plaatsvervangend chief information officer, het betalingssysteem dat verzekeringsmaatschappijen met al die federale subsidies zal vergoeden? Het is nog niet gebouwd! Dat betekent dat dit misschien wel de eerste grootschalige e-commerce-site is die ooit is gelanceerd zonder een werkmiddel om geld over te maken.
